Software Craftmanship – Writing code for the future

Software Craftmanship – Writing code for the future

Back in 2008 Robert C Martin proposed a fifth value for the Agile Manifesto: “Craftmanship over Execution”. With this value he wanted to tackle one of the main reasons why software fails, situations when teams execute but don’t care.

With this idea the goal is to draw attention to readability, stability and technical excellence. In order to accomplish this, it is often best to have a certain official development culture, with a set of standards and principles, in the team and company.

But that is not always the case. Management often refuses to allow certain practices to become official, but even in such cases, developers should not be stopped in applying them. After all, to become a professional software developer, one needs to start from oneself. Elevating yourself to higher standards can be done even if the surroundings don’t always set the path.  There are a lot of ways to help you achieve high quality code without official permission. After all, to became a better developer, you need to take pride in what you do and have something to defend.

Here are three practices, mostly practiced in the enterprise world that can help you achieve better personal productivity:

Boy Scout Rule

Always leave things better than you found them. This rule applies in every part of life and, consequently, in software development. If you are adding a new feature, fixing a bug or refactoring always think how you can improve what you come across.

But be aware, don’t do big changes. If you think something should be improved, but would take a lot of time, propose it for refactoring (just by creating a proposal for refactoring means you are still tidying up the code). Do only smaller changes to what you are originally doing, something that takes couple of minutes, like improving logging message, a better exception handling, create couple more tests for edge cases, break bigger methods in two or more smaller methods, fix the method or test name to be more meaningful, etc.

These kinds of changes don’t take much time, but will drastically improve the quality over a longer period of time.


Test-Driven-Development is a way of designing software by writing test before you write code. The goal is to think about usage of your code before you write it and use tests to think about how it should work. If you do so, you will end up designing APIs and publicly available methods in classes to be cleaner and easier to use. Using some advanced techniques of practicing TDD will help you create highly abstract modules with very high test coverages. With that we come to another product of this approach which is that you will have a lot of automated acceptance tests, edge-case tests and negative test cases that cover your code. Third effect is, such tests can be used as documentation. As I said at the beginning, the goal is to use tests to design classes and modules better.

In practice I saw several bad implementations of TDD. In all of these cases it happened because management decided to introduce it as the official practice in the company. The problem is they thought of TDD as a way to increase the number of tests. And the developers that previously didn’t work using TDD often take that goal as the absolute truth.

They end up hating it because they see it as a push to do more tests. This would result in them refusing to write poor tests, and often write tests after the code, but “selling” it as they are doing TDD.

This is why it is very important to start using TDD and practice it before making it official. The initiative to make it official must come from developers not from management.

Do Less

One of the biggest issues while working with large enterprise projects is complexity. With time, the technical debt increases, and the code base explodes in size. This makes handling that code harder with time, even when you need to introduce small changes. Even worse, if the code is not written in a way that it can be changed over time by someone who has not written it and there is no one to help them navigate it from the previous team in charge. One of the first goals you need to set is not to become that kind of a developer, who doesn’t care what will happen once they are not there to work or help with the code they wrote.

The best approach here is to always start small, and iterate small. Ignore big details, focus on the smallest details and do them one by one. Ship things early and ship often. Make sure it works and it is covered with tests. The best way to start is to apply the Single Responsibility Principle. The goal of which is to have methods and classes that do one and only one thing. This make them easy to test and easy to use.

By paying attention to detail while writing, you can make it very easy for others to read and understand. Limit yourself by making all methods you write no longer than 6 or 7 lines, and keep classes under a 100 lines. This does mean you will start slow, but you will finish fast. By using a mix of TDD and ADD, you can have acceptance integration tests that will give you the bigger picture and set you on the right path; but when you do small iterations, you write bulletproof classes and modules. Since the devil is in the details, you will stop yourself from producing bugs early on, so by the time you are done, you will drastically decrease the chances of having a lot of bugs, for the QA to have a lot of work and you will not lose a lot of time debugging and fixing edge case bugs by going through a lot of code. You lose much less time by working step by step than by fixing large bugs and edge case problems after writing a large sized code. In time you might find yourself using debugging tools very rarely or not at all!

Author: Adnan Isajbegović

Agile from a psychologist’s perspective

Agile from a psychologist’s perspective

Every person that had some connection with the IT sector knows about Agile. We all implement it in one way or another, but when something is as present as an Agile methodology, people tend to take it for granted. We now rarely ask ourselves about the effects of this methodology, since it became a norm.

I am not a developer or an engineer of any kind, but a psychologist that works as an HR manager. My perspective of agile processes is different as I focus on how it impact our thinking and behavior.

I cannot talk about whether all companies implement agile, but I can share with you my perspective of processes in the company Tacta. Here are five important effects that I observed:

Sense of achievement

Using test-driven development, makes each developer take full responsibility for the quality of the code. This approach switches one’s focus from solely finishing one’s part to making the code high-quality.

Still, from my perspective, the most important effect of being involved in an entire development cycle is that it gives developers a sense of accomplishment and fulfillment.

Feedback, feedback, feedback

Where would we be without feedback? The answer is probably stuck in our comfort zones. Doing different and new things is exciting, but it is often accompanied by a sense of insecurity, especially if we cannot see results right away. Each day we all encounter different kinds of mini choices and having someone to give us timely and specific feedback can be really helpful. Practices such as pair programming, daily meetings etc. are allowing exactly that.

Talking about challenges

In teams with more than one expert, there are a lot of different opinions. For me, transforming disagreement into a productive discussion is a special form of art and the key factors for achieving that are respecting your colleagues and being specific. In the end, joining forces to find a better solution instead of approaching the problem individually definitely makes it worthwhile.  One of the great benefits of Agile is that it offers a lot of practices that facilitate discussion.

Openness to change

Authentic change happens not when we try to follow all the plans and rules in a rigid way, but when we become active listeners. Every developer that wants to make excellent software must be sensitive to clients’ and customers’ needs and wishes. This approach requires a lot of flexibility and Agile is all about flexibility. One thing that we all could do from time to time is ask ourselves if we are still open to change and improvements or we started implementing Agile just as a formality.

Support and challenge

It can be quite difficult to achieve the balance of support and challenge in our lives. When it comes to development, support and challenge are equally important.

In Tacta, support comes in a shape of feedback and ability to openly discuss your ideas while challenges come in a shape of interesting projects and new technologies.

Sometimes challenges are greater than support and vice versa, but what is important is that we all tend to be direct and open in communication and we could create the best possible environment if we work together.

Author: Mirna Dajanović