Crafting Software – avoiding the waste
In the last couple of months i have gotten attracted to a notion of crafting software which focuses on avoiding the waste. Allow me to explain :- Once we decide what a software should do and how it should behave then we give it to the software developers. Since software is so malleable you can create the required software in so many ways, using different components, databases, architectures, design patterns etc. The act of selecting the right components for the problem at hand and combining them in such a manner that the software is easy to extend and maintain is what i term as crafting software.
The problem is, the behavior of the software we are about to craft changes often. Especially in a product company you need couple of iterations before you get to know the exact nature of the software. You need to test it on a lot of different people to get a very good idea on what features to include,discard or change.
I guess the notion of software development should be such that you start with a vague idea of what you want to develop and in time with more testing and real world use you get more insights and things will get more clear. But current notion of software development goes more like this :- you release your first version after careful crafting and then as you observe people you keep on adding or changing features. After some time it comes to a point where you realize the choices you made initially before release weren’t appropriate now as there were so many changes in the assumptions you made during the first release. You throw out most of the code and start crafting the software which is apt for the insights you got. Then one more release happens and the same thing repeats. Users will have new set of problems, marketing will get some more ideas after observing user’s behavior etc etc. The software really smoothens out only after couple of iterations which might mean throwing out existing code and re-crafting it couple of times.
So you must be willing to iterate, test and then allow yourself to throw out the code and craft from scratch again if you are serious about crafting software. So much software doesn’t have that luxury today. Some things you can do to smoothen this process are – try and choose high level languages and frameworks with emphasis more on developer productivity compared to amount of computing resources it consumers. Computing infrastructure is relatively cheap while quality developer time is not. So optimize for developer productivity. While crafting software avoid premature optimization. you will be spending time optimizing something and after launch you will see that it really doesn’t matter. All in all if you see yourself as a craftsman of software try and reduce the amount of waste while you craft the software. Like many things in life you will get better at it with experience.
Why write Code ? Because i can test it :)
ok, I might have slightly exaggerated my motivation towards why I write code but my fascination towards test first development came from learning lessons the hard way. In later part of the post i shall explain test first development in more detail but before we get there we will come back to the question – why do we write code? While acknowledging the fact that we all might have myriad number of reasons ranging from “programming jobs are plenty in number” to “writing code is just so liberating” i will repeat what Frederick P. Brooks said :-
The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.
If the above paragraph seemed like shakespearean language it simply means “When solving a problem, whatever solution you have in your mind,it is so easy(relative to other media) to put it into code. Since the implementation of your solution is trivial majority of the time will be spent on providing a solution to a problem than grappling with implementation details. The sheer smoothness of the medium to solve problems leads to the joy of coding(i added this 
)”.
But code has a tendency to grow beyond initial expectations, quickly surpassing our capacity to fully understand it. we have all experienced how end phase of any project looks like. Development slows down to a crawl. we are all busy taming many headed bugs. we wrestle with somebody else’s code just to give up or fully re-write in despair. we sit in frustration as we see countless hours of work go up in smoke while people from other departments can’t understand why programmers are taking so much time to finish off the last 1% of the project.
This doesn’t even remotely sound like the utopian land as described in above paragraphs. So if we still have to spend obscene amount of time grappling with implementation details then may be coding isn’t as utopian as some people suggest. ok, very sad truth but we have to move on. so give up coding, update your resume and try your hand at some other job. wait, i am just kidding. There are ways to bring back fun into coding. one of such ways is test first development. It is a simple process which might take some time to get used to but once you are there the process will be fun all the while solving most of the problems mentioned in the above paragraph. No i am not kidding this time – the process is very enjoyable and as a side affect it will solve most of the problems mentioned in the previous paragraph.
Test first development is a well documented process. It consists of very rapid and short cycles. In each cycle you write some tests, code enough to pass those tests and then improve the design. This is famously known as red-green-refactor cycle. Let me explain each step in a more detailed manner.
1. Red :- Suppose you are about to write down a class. First thing you need to know is get a very good understanding of what the class should do and what it should not do. Then you write a test to validate one of the behaviors. Don’t complicate anything. Take a simple behavior and write a small example as a test to validate that behavior. At this stage you have not yet written any code in the class itself. Now run the test and the test bar should turn red.
2. Green :- Now go to the class and write small code just enough to make the test pass. Nothing more. Don’t worry about reusing or repeating any code. We will get there soon. Just concentrate on writing enough code to pass the test. Now run again and see that the test bar turns green. Yahoo. Congratulations you have just written a well tested code.
3. Refactor :- Now that you have a test go back to the code and see if there are any duplications or anything that makes the code look ugly. Now that you have a test available go ahead and change the code to your hearts content making re-usable components and beautifying the code. Don’t worry about breaking anything. you have already written a test and it will tell you if you break anything. Now repeat the whole red-green-refactor cycle for the next behavior.
Each step will hardly take couple of minutes and usually when you are productive you can cover upto 20-40 such cycles per hour. let’s see how this process solve couple of problems we discussed at the start of the article.
First you are working in baby steps constantly checking whatever you have written(”The bar should turn red now…..now it should turn green…now it should still be green…now it should turn red again..”). If you made any mistake then you will catch it right away and since you know the mistake is within the couple of lines of code you have just written for the latest test it is very easy to identify and correct the mistake. No more frustration while reading through your code trying to figure out where you have made a mistake and what were you thinking when you were writing that code. One major hassle gone. Now once you commit code along with the tests, one of your team mates wrote some code in his own class which will break some of the functionality that you have written. Don’t worry the test will fail and test bar turns red. Time to stop whatever you are doing and huddle in to solve the mistake then and there itself until the test turns green. This itself will solve most of your frustrations which usually lead you to “wrestle with somebody else’s code just to give up or fully re-write in despair”. We all know that finding mistakes, not fixing them immediately, is the most expensive part of programming.
This process solves most of the common problems which are the major culprits in making you a bad programmer. Next time i shall come up with one more process which we are setting up now which should improve your code quality further. Hola and have a nice time trying out test first development. If you want more material to read on test first development, just google “Test Driven Development” and you will get enough material to quench your thirst. Any help needed please put it in comments and i will be glad to help.
