Monthly Archives: August 2013

Why Sign both the Manifestos Agile and Software Craftsmanship ?


This question is more like you what if you were asked to sign for two rival organisations one pitted against the other. In a communist regime it would be akin to siding with the dictator and other with the rebellion groups at the same time. On one hand we had the agile manifesto which brought to the table best practices of XP which later took over to Scrum and now there is movement called Software Craftsmanship which is gaining momentum. It was always there but it just that it is resurfacing itself with more necessity now. Need a Surgeon who follows all the procedures correctly and also does a good job of the surgery. This is how we need to see both these movements Agile and Software Craftsmanship movement.

What is Agile manifesto ?

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Remember the initial agile thing  that we got to practice was that of Extreme programming and it sounded as if we were doing something out of the way. Not certainly new things but old things in a newer faster effective way. It got people involved in the whole process and brought a lot of mileage and visibility in the organization. A little later came Scrum and other lean and mean characters followed.

While all of these got practiced by people , the craft of delivery good software got lost along and it became more of a process rich methodology with backlogs, sprint run race velocity and a lot of jargon thrown along the way. We left the main essence of all our work which is to write good software aside and got carried away by all things agile. Little realizing that if we sulk on writing good software then it will eventually slow us down no matter agile or otherwise.

Just as we have good engineers doctors who take pride in laying a state of the art bridge or performing complicated surgery , an expert software person these days is almost dealing with the same set of tools and many a times doing mission critical jobs which are at risk if we leave the craft aside and focus on delivery alone.

 What is Software Craftsmanship ?

  • 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 partnerships

Why we need Craftsmanship in good measure along with Agility ?

Technical debt increases in the project as it progress if the initial thought process to create an architecture which forms the bedrock promoting flexible changes end to end is shallow and not done correctly.

Most often we know how quickly we ended up doing a POC or the initial releases of the product. As we progressed things got slow to the point where there were instances where a customer wanted a font change or a logo change on some index.jsp but we ended up saying it is going to take some obscene amount of time citing organisational procedures, bureaucratic red tape , QA , testing of all forms , our platform certification practices etc. This is true of even the big boys when we request a small change in any software of enterprise level, all we get to hear is yes we have considered it but gives us time till next release and we will put it right back in there. All of this is familiar to most of us when things looked quick doable in a jiffy but as the product matures ,egos rise and technical and product debt increases we find ourselves like the rain starved farmer looks at the skies for divine intervention. This could have been avoid if we focused on Software Architecture best practices and craftsmanship of some form. The better the skill less is the debt . We have existence at all levels so we could have various forms of craftsman some more skilled than the others and others not even acknowledging that there needs to be one on the team. If we do not pay heed to software quality and design principles , architecture best practices , code best practices and correct things then and there we will be debt ridden and eventually end up with the debt being written off meaning scrap the product line and look at rewriting this.

There was this joke going around in one of the companies , there are 50 people working on re-factoring the product and the unofficial hear say was you need half the time and only 15 people to rewrite the product completely from scratch. Most often you cannot digest the fact that scraping something altogether is worthwhile , just as we have an old item in our house that served its purpose but now occupies space and does less. Of course while we value that it served us well and enabled us to get this far and when we want to do something different then we should be able to redraw our priorities and align our needs accordingly. Writing good software is an art with more of a process like if we get X people certified on Y technology then we can reap Z benefits over a period of time. This rarely works although most often this gets practiced everywhere. Just as of all the people who learn a language only some manage to write poetry that can move minds and souls. It may not be a good analogy as we have fewer poets than software engineers these days.In a similar fashion while we need agile practices to help us quickly add scale to our operations we also need to have the craftsmanship part of it to go hand in hand. Else we will have a process rich methodology without craftsman who can execute on the promise of the Agile story. We could look at in more detail what constitutes craftsman ship in an other thread.

So sign up for both if you want to sow the seeds as well as reap the rich harvest.

Why are benefits difficult to calculate in software investment ?

Cost benefit analysis is a good tool to estimate the ROI based on investment in software. It is a simple formula that says

Cost/Benefits Ratio = Benefits of the Solution-Product /   Service Cost of investment.

This simple looking formula enables ones to calculate the cost of investment against the benefits of the investment.

Let’s say we have two competing product line items one of them being revamping our click and install strategy and the other one being upgrading to a new application server. Let’s say the click and install strategy brings to the table the benefits of a literally one click install and there are no ambiguous things in the installation and every thing that the customer/ install engineer needs to do at site or on the target box is well defined and crystal clear. This is an area which involves folks from different modules to collaborate and provide their inputs to the installation team.

Overall what does this involve : Individual teams ( collect all your artifacts and hand them over to the install team) , install team ( collects these artifacts and includes them in their batch installation process/software reorganizing what comes first and second and so on). Now this simply means two teams at work one team is simply a provider of data having very little to do from their side at least at the start of the program to enable the grand vision of a one click install. The other team is busy with the data obtained from teams and busy fine tuning their install elements and getting the software installation in place. Lets say individual teams put together spent 5 developers ( 2 days ) to flesh out the details and around combined effort of 2 man months ( 5-6 developers from each team fixing the the changes for the single click install – this could have further broken down into consultants / developer partners and members of the company – aggregate the numbers here and total them into man months and convert them to a FTE and say you arrive at 2 man months of effort. If we calculate an 8 hour work week then if the charges are around 300$ per day by some outsourcing company and let’s say the cost to company of a in house developer is 100$ ( minus salary / training / benefits etal) . To keep things simple we say 2 man months was the combined time taken across teams to release this feature meaning a shippable product with rounds of QA thrown in adequate measure.

Cost of spend on one click install  =  2 man months * 60 days ( holidays included) * 450 ( Average rate of internal and external teams) = 54,000 $

Lets say check benefits of one click install  :

Banks operational staff is cheerful with rolling releases / bug patches and defect fixes. They talk good about your product with other vendors who are SI at a particular engagement.It takes only one of the usual Joe’s to fix and avoids 4-5 people late at nights on friday weekends. ( This is tangible direct revenue can be associated with this / weekend / late night allowance included in happier times else it is sheer push that works from one and all to get the rollout ).The support team uses less cuss words and your effort begets good karma. Wait and watch. Apple effect to follow.Earlier if the rollout took combined effort from several teams for a stretch of days on end and finally breathe easy now you can probably do it in much less time . Tangible value here as well.

On the other hand let’s say the application server install  let’s say took 2 people from 5 teams to finish the work internally without outsourcing in 3 weeks time and this adds up to 2 (developers)* 650 (per day rate) * 5*15( days) = 97500 $

Cost of spend on application server migration = 97,500 $ + 50,000$ License fee of the product certified.

Now if you have the product rolled out in different markets then cross sell , up sell opportunities can also add up to revenue. Can this could make up for sunk capital on this feature. But again this would be from a pure financial gain point of view.

Benefits of migration to application server migration : 

You are seen as leading technology changes from the front. Customer gets to know from you directly instead of he having to ask you to migrate because the rest of his surround system is already on the new platform and having to pay recurring license on an off the shelf product is becoming expensive and illogical. As you grow bigger your problems are bigger. There was a case in point when someone wanted a feature to be turned OFF in the product, that was in itself a project and not justifiable. Here again technical debt , software craftsmanship and other in the fraternity come in handy if you were pally with them initially.All of this call for a definite method in the madness approach. Do you have teams who look at software delivery like a relay or more like a close knit game were all are involved from start to finish.

Now coming back to the question of tangible benefits it would less memory footprint , better resources and more value for money spent on the hardware boxes. CTO heard less of our investment in X9000 series machines with Y investment still chokes on wednesday at 11.00 am every week. Less memory footprint would indirectly increase CPU responsiveness and provide more head room for multiple applications to work along side without peaking and frozen behaviors.  You can arrive at some benefits here in terms of saving and additional hardware resources or if you are in the cloud already think of less pay as you use cases. Some tangible benefits. Attaching precise X dollars is again a challenge as many factors would be involved. 

Lets say you have brainstormed internally with your teams and arrived at cost benefit analysis for three solutions at a prototype level and are stuck at which one to pick. Then the following calculation would be useful. But there is usually more to it than just the financial aspect to it as we saw above.


The above is a cost benefits analysis for three competing solutions and solution Y has the maximum benefit to the cost incurred if we were to consider from a pure financial point of view. Most often technology folks are immersed deep down in technology issues and challenges and at times do not see this side of the story. But the decision makers and people who approve the cost of spend on technical projects would need this and additional mechanisms such as PERT ( where probability or chance of success also is a parameter in the calculation ) to arrive at or narrow down the choices before sponsoring the projects. At times we even have rational such as we have some additional folks on bench so lets kick start this project on the side and add value along the turns. In such instances we incur benefits once the software is delivered value realized and when we are able to push the product out there in the market.

There is also the story of twitter , you tube which for the longest time were funded with out any benefits in sight in such cases the above rationale does not hold much weight except of course for making decisions which eventually made up the twitter or you tube. Anyways it is nice to be equipped with this knowledge at some point of time and if you are continuously innovating then obviously the value is hard to calculate and benefits are bound to flow. So know when benefits need to be applied and when innovation culture precedes all then benefits although intangible is an immediate after effect.

Use calculations with the knowledge that you have on systems and then benefits would become easy to comprehend and calculate. So the question remains at large although answered on some fronts.