Agile development team member mantra


Introducing code review and pair programming has often an impact on relationships in the team – especially when a critique needs to be delivered. It takes great degree of experience on both sides to communicate defects in the code for both the reviewer as well as for the code author to get something useful out of it.

I found this at which can be helpful (page is 404-ing now, but I luckily saved it in Google Docs way back) :

Everyone, including me, repeat after me:

  • I am not my code. A criticism of my code doesn’t have to be a personal attack on me.
  • I am not the tools that I use.
    A criticism of my tools shouldn’t be construed as a personal attack on me.
  • I am not the programming language that I use

I will try to remember it (and read it to all participants) next time we get into the passionate discussion about whether inheritance or delegation is the correct approach to implement feature X 🙂

On hardwood floors and software engineering


I am in the middle of a non-computer related project. Last week we have decided to get rid of carpeting in my home office and library and to put in the hardwood floor. My wife picked the wood and color, I picked the contractor, with my son’s help we moved out the furniture and the renovation started. The most painful thing was shutting down and disconnecting all the computers and servers – only the lonely router is hanging on the wall and suffering the dust and noise of the power tools. As result, my family is now server-less and until we finish and connect them back, we have to survive using the notebooks only. Fortunately, I have at least one notebook available for each household member, except the cat. Even more fortunately, she (the cat) does not mind.

Surprisingly, this project reminded me of something that is so familiar when you are working in enterprise IT environment and deal with real life systems and real companies: you cannot do just one thing. After we uncovered the carpets, we have discovered few hidden issues that had to be fixed before we could put the hardwood in. In process of fixing it, another issue popped up and we ended up replacing the plywood that was under the carpet. As result, what was supposed to be done in 2-3 days, will take twice as long and will carry according price tag. In all this we are extremely lucky having very good, capable, hard working and honest contractor doing the work.

So, does all this renovation have anything else in common with software engineering? I think it does. Year or so ago, we had this discussion about metaphors, paradigms and models for the software development process. One of the discussion’s topics was why is our (presumably engineering) profession so bad in estimating the time and effort required. Look at the guys building the houses – Steve challenged us – they can tell with 5-10% precision when they will be finished and how much will it cost. Even better, when customer changes his/her mind in the middle of the project, the impact of the change on timeline and price can be determined with fairly high accuracy.

We have talked about obvious differences between building a house and building a software system. The house is pretty much always the same – can be bigger or smaller, but the variations are very small compared to possibilities of software systems. There is very small selection of materials, the components are well standardized and the process of building has been tested and fine tuned on millions of houses built. The workforce in construction business is very much standardized as well – the productivity can be easily measured and deviations between the most and least productive worker are much smaller than in software world. The laws of physics help too – by making the completely wrong combinations of components more obvious and easier to spot. In short, construction of a house is bad metaphor for building a software system.

What seems to be much better metaphor (if we have to stay in the realms of construction business) is house renovation. Here you have to make assumptions and will make discoveries as you progress – and this maps nicely to the process of requirement “gathering” (whoever created the term gathering was idealist, in reality it is much closer to digging for requirements, but back to the topic). You start assuming that your job is to put in hardwood floor – or to integrate two software systems. In reality, your job is to resolve unknown number of problems of unknown complexity in order to even start.

You have the legacy of existing house, plumbing, infrastructure – similar as you have legacy enterprise systems, databases, data feeds, business owners and so on. You may be aware of some them before you start, but their true size, nature, status and complex interdepencies will became fully understood only during the process of renovation (or integration).

So what is the moral of the story and what is the right approach ? I have no answer that would work in every situation. What worked for me – is honest communication and transparent decisions. Make sure that the customer understands what is included in the estimate, what are your assumptions and what can potentially be hidden issues if there is an indication you may find some. Whenever you discover something that may change the scope, do not delay telling the client and make sure he/she understands all possible pathways and their consequences.

Be generous – if you need to invest extra time to make sure the recommended decision is the best option for the client, invest that effort regardless whether the cost will be covered by the client. If you go that extra mile, in long run you will be always rewarded – with repeated business, better rate or at least the good karma for doing the right thing.

Document all agreements, discoveries, options presented and decisions – they may be great reference when facing similar decision in your next assignment. And sometimes the document trail you leave behind may be only existing documentation of the system in question. The contractor that comes next, will thank you for that. If you do your part properly, that somebody may be the future you.

BOTD: Raganwald by Reg Braithwaite


Many good posts about programming, coding, business, aesthetics, with nice touch of wisdom, If you are into programming languages, do not miss this one, this and this. If you are more into process and management, try this and this or this. There also deeper and lighter stuff 🙂
As Reg says about popular bloposts

One model for popular writing is that it panders to the reader’s prejudices. Plain and simple. People like writing that validates them and especially their ideas.

He certainly does validate mine, which is the reason why I made it blog of the day :-). Find for yourself.

Ruby is in top ten programming languages


According to the TIOBE Programming Community index (which gives an indication of the popularity of programming languages), Ruby jumped 3 places and made it to top ten. Congratulations !

If you look closely on the trends down on the page, the dynamically languages popularity has risen over 3.6% during year period. Which is A Good Thing (TM).

Should I make my personal Top Ten of the programming languages, ordering languages by my degree of comfort of using the language, the language beauty (which is, in the eye of the beholder ;-)). Factoring in also how much I do enjoy reading/writing code in that language and it’s usefulness from both personal as well professional point of view, the index would look like this:

  1. Java
  2. C#
  3. Ruby
  4. SQL (both T/SQL and PL/SQL)
  5. Javascript
  6. Objective-C
  7. Python
  8. Shells (mostly BASH)
  9. Perl
  10. VB.NET

First place is practically tie – as the Java / C# are in reality more two dialects than two languages. They were very close at the beginning and with latest versions (C# 2.0, Java 5) they got even close. As it looks like, in the future they may diverge more with all the LINQ stuff coming in C# 3.0. I like Java portability, amazing variety of open source code available – and the development tools are IMHO still better on Java side (Eclipse, IDEA, Netbeans), but C# syntax of properties is nicer and there are slightly more commercial opportunities with Microsoft platform (at least during last 3-4 years).

The only “real” compiled language in my list is Objective-C, for which I have absolutely no commercial use for right now, but I hope that will change one day when the greatest of all cats finally arrives. Neither C or C++ made the list – the only encounters with C these days are during installations of Ruby GEM on Linux or Mac platform – which often comes with native part in C source – and the installer barfs at me with some gcc error :-). And despite using Mac for over a year now, I felt no need to write anything bigger than Hello World in AppleScript