Making Good Software

A blog by Alberto G (Alberto Gutierrez)

Archive for July, 2011

Agile: The good, the bad and the ugly.

with 5 comments

Most companies are adopting Agile as the “de facto” process for their new projects, while is clear that overall is better than waterfall, it still has its defects. This article does a brief overview of what is good, bad and ugly about agile.

The Good.

Embrace change. Change is the only constant in software development; not embracing this is like swimming against the flow. Embrace change is precisely Agile’s motto. Agile supports change by developing in short iterations, which allow for faster feedback and consequently allows for changes in the features to be developed.

Empower programmers. Good, empowered programmers make good software. But that’s not easy, agile empowers programmers by giving them the most important role in software development moving it away from contracts, schedules and management.

Disregard BDUF. Big design upfront is one of the major signature features of the classic waterfall developments, not a single line of code is produced until a complete design of the application is completed. This is not only bad because it goes completely against embracing change, is also not realistic since any complex design has too much uncertainty making it impossible to produce a complete correct design upfront.

The Bad.

In some cases, an extreme approach to Agile may cause some issues, which from all of them IMHO the next ones are the most relevants:

Too much focus on the code. All code sucks, pushing too hard to produce beautiful code is pointless. This doesn’t mean that there aren’t big differences between different codes, there is code that is terrible and there is code that is alright, but there isn’t beautiful code. Unfortunately extreme agilists tend to push the idea that the beautiful code is achievable causing developers to spend too much time looking after it.

Complete disregard of design. BDUF is bad, but not doing any design at all is also bad. In extreme agile there is a tendency to let the code drive the design, which is the opposite of BDUF. The ideal situation is a healthy balance where some informal design and thinking are performed before coding, then some coding, then some more design and so on.

The Ugly.

Apart from tendencies which are clearly bad, agile also promotes some other practices, which while not being extremely bad feel like a waste or like they add very little value.

Holy events. In agile there are many activities that the team performs religiously, like stand ups, planning meetings and so on. These activities are performed like mass, forcing the same structure and same formulas all over again. These “holy events” usually add very little value and may even become a communication anti pattern.

Alternative estimation methods. Accurate software estimation is impossible, for two main reasons, change and uncertainty. Ironically some agile families still try to provide with some sort of reliable estimation mechanisms.



Written by Alberto Gutierrez

July 31st, 2011 at 4:07 pm

Managing crises effectively in software development projects.

with one comment

In a green field project, there is always an initial euphoric phase where everything is great.

Unfortunately, sooner or later things turn for the worse and the first crisis hits the project.

  • You cannot avoid having a crisis, but you must manage them. There hasn’t ever been any project that didn’t have a crisis, and yours is not going to be an exception.

Crises are about not being been able to meet expectations and they involve different actors, including “the business”.

  • Manage expectations, make sure that “the business” understands that having crises is normal, and do it before they hit you; the best period is the honeymoon that is the start of the project. Sit with the business and explain what your crisis plan is, availability, backup plans …

Crises can be sometimes prevented beforehand, the worst type of crises are the ones caused by development not being honest with the business, common examples are not telling that the development is late or lying on the real set of features already developed.

  • Be transparent. Managing a project is to take responsibility when things go wrong and making sure that all the stakeholders are well informed of what is the current status of the project. Hiding information is never good in the long run.

Unfortunately, one of the most difficult activities is to learn what the real status of the project is. There are many projects that died because it was discovered too late that the project was heading the wrong direction and it was too late.

  • Be aware of what the real status of the project is. Many project managers are so much obsessed with only reporting green light to upper management that they live in denial. Gather as much information as possible, disregard subjective information as “this should be fine”, or “we are almost done”.

The budget and or the schedule, can’t be both sacred, that’s one of the toughest realizations in software development and one of the most difficult things to explain for project managers, the main reason for this is uncertainty, there is always a lot of uncertainty in software development that causes a lot of change.

  • Manage change and uncertainty. Be aware when the conditions of the project change and make sure that the necessary actions are taken to accommodate the project to the new conditions.

Even when the project is under control, you still are going to be face with crises, but they are going to be crises of a different nature, mainly accidental nature: data lost, hardware failures, bugs…

  • Be always ready for accidental crises. Have an emergency plan, you need to know who, how and when can be contacted in case of emergency and what availability they are supposed to have. You also need a data restoration plan. Most importantly remember to do fire drills: Simulate crises in a production like environment and make sure that everything works as you expect.

As already mentioned, there is nothing that can fully prevent you from having a crisis, so when they do appear, make sure you react accordingly.

  • Be professional. React calmly but with decision. Focus your energies in finding a solution for your crisis.

When there is a crisis, the project mentality switches to emergency mode. In emergency mode everyone should be given the 110% of themselves, this is very productive, but also, very stressful.

  • Try to spend as less time as possible in emergency mode. When you spend too much time under a high quantity of pressure you will start becoming less productive.

Too many crises in a short period of time is usually the sign of a major underlying issue, the worst remedy is to keep the team in perpetual emergency mode trying to extinguish all the fires at the same time.

  • On perpetual crises. Stop, analyze the situation and tackle one crisis at a time. This is sometimes very difficult to explain to the stakeholders, which may expect immediate solutions, but is the only way out in the medium-long term.

Unfortunately crises are also usually recurrent, and they keep reappearing.

  • When tackling a crisis be sure not to focus only in the consequences, but also the causes. A crisis should be fixed with guarantees that it won’t happen again in the future.

One of the biggest differences between software development teams is how they react to crises, being able to manage them makes a huge difference. Keep in mind that many times making mistakes is not as important as how you manage the situation after a mistake is being made.

Written by Alberto Gutierrez

July 17th, 2011 at 3:47 pm