Category: maintenance

Everybody Needs ... Unit Tests

February 5, 2009 by Przemysław Bielicki

Picture courtesy of Lotus72@flickr

... please remember people, no matter who you are, and whatever you do to live, thrive and survive, there are still some things that make us all the same: you, me, him, them - everybody, everybody! - this is a fragment of Blues Brothers' "Everybody Need Somebody" song. Nothing to do with software development but when you change the next line of this song from "Everybody needs somebody" to "Everybody needs Unit Tests" it becomes closer to software development.

I intentionally used lyrics of this song to keep everyone's attention (just a little bit) to this post. If you are familiar with TDD and unit test your code you can disregard it - I'd like to address this post to all software engineers/developers/programmers/etc. that DO NOT unit test their code.

In this post I will try (again) to convince all software developers that still don't unit test their code that it's right thing to do and it's damn simple.

How to Do Many Projects (Part 3): Maintenance

October 21, 2008 by JurgenAppelo

In two earlier blog posts I described how we have organized the software development efforts in our company. I wrote about cross-functional teams and matrix management.

This time, I'd like to talk about software maintenance.

I have recognized two lines of thought regarding maintenance:

1. Software maintenance should be separated from new software development. This means that, when a software development team considers a project finished, it is handed over to a maintenance team.
2. There's no clear difference between software maintenance and software development. A team should perform both new development and maintenance.

Personally, I lean towards option 2. And these are my reasons:

Maintenance victims - Handling maintenance the Agile way

May 2, 2008 by Artem Marchenko

Bugs used to be something very distracting and unpleasant for the software developers. For management they can be even worth - the effort and time bugs need to be fixed is poorly estimatable. Sometimes these number are complete question marks. This predictability drop is one of the reasons why agile methods advocate striving for bug-free development as possible

Scrum teams don't like bugs just as any other teams. There are multiple approaches to handle bugs from entering into the product backlog and making them wait until the end of the sprint to allocating some "maintenance slots" in the sprint to a more-or-less expected amount of maintenance. The sad truth is in that amount of bugs discovered and amount of time needed to fix them is often not predictable even roughly. Especially for teams that are not yet used to deliver the tested features.