Software Craftsmanship

Thanks to Uncle Bob I found the Manifesto for Software Craftsmanship. Is is built on top of the Agile Manifesto. Since it is short I will, repeat it here:

Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive

After reading and signing it, my mind brought me back to my job. This week was especially challenging. A system I inherited had several production issues. I did not ask for the system, nor do I respect it. This attitude has led me to treat it with disdain and thus not do my best on it. I let my guard down and did everything I know to be bad practice (e.g. no unit tests, large methods & classes) just because the code base was in the same vain.

The first item above struck a cord with me. I had working software, but poorly crafted. It led to a stressful week for me when I could have done better and prevented the problems. I often find myself in situations that appear to be no win. All my friends and colleagues agree with me. What I fail to do is realize this simple truth:

If you don’t like something, change it. If you can’t change it, change your attitude.
Maya Angelou

I am going to attempt to stop complaining about the hand dealt to me and strive to do my best . This will hopefully lead me to achieve the goals in this manifesto. I will also try not to enable those around me to adopt the same SSDD attitude that leads them to do poor work. I know I will fail more than I succeed, but it is nice to write it down and join a large group of other similarly minded folk.

First Time Quality

I was listening to the stackoverflow podcast #10 in which Joel (of Joel On Software) stated that code should be written in two phases. The first phase in which you get the code to work and then a second phase in which you improve it. He also states that most of the time you never do phase 2 unless the code is important. I used to work this way and assumed (as Joel does) that this is the best way because I was so smart. I have since learned the importance of first time quality. I still haven’t turned this knowledge into action all the time as I still write code that embarrasses me 🙂

First time quality was something Deming wrote about in his 14 points. Particularly point 3:

“Cease dependence on inspection”. If variation is reduced, there is no need to inspect manufactured items for defects, because there won’t be any.

Obviously Deming isn’t writing about software, but the concept is similar. Testing software at the end is the same as inspecting manufactured parts. The quality of the code is already determined. This should not be news to anyone. Take this one step further, and when should you spend time making the quality better? The answer is obviously as soon as possible. Thus the better you are at writing good code from the beginning the better and faster you will be. For the rest of us (not a Done, and Get Things Smart person), this means we must get better at seeing poor quality and improving it as quickly as possible. To me the only way to do this effectively is if you write your code incrementally with quality checks along the way. I don’t know any method better than TDD to do this.

When doing TDD correctly I find that I can sense the internal quality of the code. I like the term Code Smell for lacking quality, but I also sense when things are going well. I sense that the software design is growing in such a way that new features are going to flow out of it. My productivity soars. This phase usually doesn’t last long as I inevitably do something stupid and cause the code to bloat with duplication. The beauty of TDD is that is allows these modes of hyper productivity while being a safety net for the times of hyper stupidity. I am not saying that TDD will cure all the ails of software development. As long as humans write code there will be ails. It is in our nature. I just know that true first time quality is such a boost to overall productivity that it saddens me that more people don’t do it. I think one of the reasons for this is that we have too many software developers that should not be doing software, but that is a topic for another post, another day.

Project Change, a Way of Life

I just read  Project Change, a Way of Life by Jurgen Appelo (http://noop.nl/ProjectChangeWayofLifeV1.pdf – ~2mb) and I thought it was worth the read. His goal was to “link complexity science with agile software development”. He starts with change is the only constant which leads to the iron triangle. For some reason he puts the attributes on the apexes and not the sides (I think this hides the most important aspect of the iron traingle, but it’s his article).

Next he goes on a diatribe on the term “project” and decides a better term is “product” (which is the goal of most software projects – sorry I just couldn’t help myself). He then gets to an interesitng discussion on success which leads him to this:

I believe that every software product is a success, until it fails. 

I think its a good way of looking at it. He talks alot about his car…he is young after all. He uses the term fitness from biology. Fitness is a relative term about how well a species survives in their environment. I like that: a product’s fitness is the same thing. Take a product out of it’s environment and it could do better or worse. Put other products in it’s environment and it might be more or less usefull.

He calls the game of improve or die the Red Queen Race from Through the Looking Glass. Products change to keep up with the competition or they are no longer used and die. Your nice document management system will lose to a package that costs money once the feature difference is worth the cost.

He then goes into Fitness Landscapes, which a neat idea, but I don’t see a strong correlation with software products. I disagree that people can do “conscious selection” well and natural selection is not well characterized as being random. Now I am just nitpicking. Like I said in the beginning, I think this aritcle is worth the time it took me to read 28 pages.

Why do decent people use the waterfall method?

It seems everywhere I go the waterfall method dominates the mindset of the management and most of the technical staff. I wonder why that is? It seems to me that any rational person would admit that the cost of fixing a defect grows exponential as time passes from the moment it was introduced. Most rational people would admit that in the waterfall method most defects are caught at the end of the project life cycle, thus guaranteeing they will be very expensive to fix and that most project will have to resort to testing the quality up to a level that is relative to how late the project is (the later the project the more defects they will consider shipping). Given these assumptions, why do any project using a method that caps the outcome to mediocrity? Maybe my own past can help me understand this.

When I was first paid to do software (circa ’91) I thought the right way to do software was the waterfall method. It was what I learned in Grad school as part of the Software Engineering series and it seemed everyone I met was using it in one form or another. When my job involved the CMM it fit very nicely with this belief. Anyone who though differently was obviously a Cowboy Programmer and was just too lazy to do a professional job. Being young gave me such confidence (ignorance seems to do this).

As I gained experience, I started to doubt my belief in this classic approach. I worked once with a client who gave me new requirements every other week or so and my team of two gave him working code every week or two. It worked well, but I didn’t think why. Later I started teaching others how to deliver software on time and started to really question my belief. I saw projects being executed by CMM level 3 and higher organizations consistently go over budget and deliver sub par systems. About this time I read some Agile books, some Lean books, and the classic paper by Gilb “Evolutionary Delivery versus the waterfall model” and though what a dope I had been!

I seemed to have overcome a belief that wasn’t founded on solid principles, but others seem not to. Humans tend to behave in irrational ways in order to “fit in”. Maybe what I see is just a group dynamic caused by fear of the unknown. They know the waterfall method and the devil they know is better than something they have never tried. The more I think about it, it reminds me of OO adoption. Back when I first read about OO in ’92 (and it wasn’t a new idea by any measure then) I thought this is got to be the way to program. It came naturally to me, but it was years before I was in the majority.

Maybe Agile/Lean (Whatever you want to call it) just needs to ride the adoption wave until the majority accepts it. Then the fear factor will be with those who don’t do it? Then some new idea will come along and some guy will blog about idiots like me who do it the “old way” 🙂