The Boring Software Manifesto: XI to Eye

xitoeyeOver the years the term “agile development ” has been co-opted to mean something it’s not.  “Agile” does not mean the ability to change things at the last minute. In fact, when it comes to development, this kind of excitement is overrated. Sometimes boring is best.

In this edition of XI to Eye I present “The Boring Software Manifesto.” In a Boring Software Process, we use continual steady improvement, automated test suites, and an understanding that requirements change to prevent surprises, and allow us to focus on the problems that are actually interesting. That’s it. No heroic measures needed.

Watch this short five minute video to hear more about agile development, the way I see it.

Noel Rappin

About Noel Rappin

Noel Rappin has written 8 post(s) in this blog.

Facebook Twitter Pinterest Plusone Linkedin

3 Responses

  1. Ryan Wilcox says:

    Absolutely agreed that Agile such a great word with positive meanings that it’s overused. I thought Scrum was named this because the originators thought that nobody would willingly call their software development process “scrum”. (How wrong they were).

    But of course “agile” sounds so great and positive that everyone does it – because not saying your agile sounds like you’re old, crufty and slow. And who wants to be that?

    So every company says they use Agile, so it becomes useless. Companies with daily standup meetings and a waterfall design/planning process? Agile. Companies that have must-meet-inflexible deadlines every month (err, excuse me, “sprint”)? Agile. Companies that have no idea what they are doing beyond the next week? Agile. Places that practice sustainable development based on feedback where all sides are equally valued? Agile. Places where all the requirements and designs are specified up front but they pair program? Agile.

    So now when you see agile on a company’s website you have to say, “What does Agile mean to you?”, and hope to read the tea-leaves enough to not get yourself into a bad situation.

    I applaud any effort that strives to give definition to developer working conditions inside a company or team.

  2. I think I agree with most of what you’re saying here with one exception. I don’t understand the “automated test suites vs random bug discovery”. Can you explain this in more detail? I am mostly disturbed by the word “random”.

    Without any explanations I could interpret this in strange ways.

    Are you contrasting automated tests and manual tests? In this case, I can’t see how manual tests are supposed to be random as opposed to automated tests.

    Are you contrasting the methods for finding issues in software? In this case, I still can’t understand what “random” means here because, for example, using automated tests and exploratory testing hand in hand can both be on the green side.

    Are you contrasting “automate all!” vs “nothing is automated!”?

    Are you contrasting “skilled testing is done (and automation is used for some of it)” vs “no skilled testing is done and people stumble over bugs randomly”?

    I think the other points are fair to make and the way you have reframed some of the problems is very helpful. But this testing part is… dangerously unclear.

  3. Scott says:

    I have also been found guilty of changing stuff all the time in the quest to achieve heroic measures :)

Other Posts