Making Good Software

A blog by Alberto G (Alberto Gutierrez)

Written by Alberto Gutierrez

July 31st, 2011 at 4:07 pm

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.

 

 

5 Responses to 'Agile: The good, the bad and the ugly.'

Subscribe to comments with RSS or TrackBack to 'Agile: The good, the bad and the ugly.'.

  1. Hi,

    I know this is just your introduction phrase, but really are you sure that “Most companies are adopting Agile as the de facto process for their new projects?” I really doubt it.

    It nice for the rhetoric effect, but is likely to be false.

    Nicolas

    4 Aug 11 at 1:34 am

  2. Hi Nicolas,

    Thanks for your comment, you are actually right, what I am saying there is based on my experience and not facts, so might as well be false. What do you guys think? In your experience, is agile the ‘de facto’ new process for new projects in most companies?

    Alberto Gutierrez

    4 Aug 11 at 2:31 am

  3. I like your comment about Holy Events. Most stand ups are useless and some turn into a monologue from a manager.

    On one agile project a manager moved our twice weekly stand ups into a meeting room where he made sure that they all lasted the full half hour the room was scheduled for. If the room wasn’t scheduled immediately afterwards the stand up would last for an hour.

    Dean

    4 Aug 11 at 5:31 am

  4. Hi Dean,

    That what you say about your project manager is amazing, jesus fucking christ… Hope you don’t have to deal with him anymore

    Alberto Gutierrez

    4 Aug 11 at 7:33 am

  5. Very nice post. I agree with Nicolas and his views on Agile. I would like someone from QA testing background to share his or her experience using Agile Methodology.

    Lisa Davidson

    1 Sep 11 at 11:39 pm

Leave a Reply