Arkisto: September 2012

A Monologue Backlashes in Product Development

25. Septemberta, 2012 | Kirjoittaja: Antti Niittyviita

Last week we discussed a project that was already a month late from its schedule. Since money governs the businesses and testing has to be an investment, we decided to find out what was going on: We interviewed the project group.

Product development cycle in the business was 3 months in entirety and testing was emphasized in the end stretches of the cycle. After the interview we could state that the number of bugs found during the last stretches of the cycle had, like always, caught the software development by surprise. However, the number of bugs was not their greatest challenge. Fixing the problems just took a confusingly large number of time. Why was this?

Let us think about the situation where Calvin the Coder builds a new feature. The number of lines can easily number in hundreds. Then Calvin’s code from August-September reached the testing phase in October and bug reports start to emerge the fixing process can start. But what do you think? Can Calvin remember what kind of changes was done to the code in August?

Is it a wonder at all that digging through old lines of code can take so much time?

We stated that the same problem systematically plagued projects whose product development cycles were long and where testing was emphasized on the last stretches. First came the coding monologue, then came the testing. The product development was and stayed sticky. We figured out two possible solutions to the problem:

  1. Speed feedback cycle by forcing developers and testers to a dialogue
  2. Budget the project a plenty of time to fix things and hope for the best

You do not have to be a rocket surgeon to guess which option the product development lead chose.

Product development is always a team game. Quality includes staying in schedule. Only a fast dialogue between testing and development can guarantee fast results.

But it isn’t Worth in Investing in Schedule!

21. Septemberta, 2012 | Kirjoittaja: Antti Niittyviita

We dug our claws into a project, whose delivery day had been postponed by bugs found at the last minute for over a month already. Nothing new under the sun, we stated. This software development cycle had already been done for.

During the lunch break of the starting day we stopped to talk about money, like we have a habit of often doing.

When a project is delayed, what does it mean from the perspective of the project’s turnover or budget?

If the product development team takes 15 people’s full workload in a month, then a careful estimate would place the extra month of fixing bugs as costing dearly for their employer.

According to service, a software developer’s average salary is around 3600 euro. With the employer’s side expenses and holiday salary the entire expense comes to be around 5400 euro. A team of 15 people would therefore cost around 81000 euro in one month. (*)

The direct expense caused by a delayed project is rather high. The budget cannot hold and profit margins get swept even though the project could be a long one.

The delay costs not only money. The client can wait for the update with eager anticipation. The feeling of disappointment is pretty difficult to heal. In future, potential deals can be postponed, even remain entirely unborn. The resources allocation of the business gets disturbed, since the next project does not gain the people it was intended to get. In the end, even that project gets delayed. What we have then is a running start. Effects flood into my mind, when I stop to think about it for but a moment. Suddenly, a question springs into my mind.

How much would you be willing to invest for a project to remain in schedule?

(*) In reality, the expense is even greater when you consider work benefits, health care and tools!