Tuesday, September 1, 2009

Software development: It's all about trust ...

trapez.jpg Software development is a lot about trust.

But It is hard to trust someone, if you really do not understand what he is doing. It's even harder if you suspect that he does not understand what you want!

This is a major problem in enterprise software projects:
  • The software creation has become a very complex and intricate undertaking that requires a lot of specialized knowledge.
  • Since enterprise software development is inherently dealing with change, it is almost impossible to know what a solution is going to look like.
  • Enterprise software development is still a very young discipline that has grown unreasonably fast and that is still very much in flux. It is almost impossible to rely on experience or best practices.

  • In traditional enterprise software projects we create a lot of management overhead to deal with this situation: complicated contracts are created, detailed project plans are conjured out of thin air, budget arrangements are negotiated, unrealistic progress estimates are enforced, change-requests are fervently tracked ...

    All those activities could be considered as engineering activities. But software development is turning out to be less and less an engineering discipline:
  • Tom DeMarco: Software engineering: An Idea Whose Time Has Come and Gone?
  • Joel Solsky: How Hard Could It Be?: The Unproven Path

  • Thinking about it, all this overhead is mostly about establishing trust. If the trust is not there, its about safeguarding and establishing a position to lay the blame on someone else.


    Obviously the above situation is hardly satisfying for anybody (except maybe the lawyers). Lots of efforts and resources are wasted. It's hard to focus on what should be everybody's goal: creating meaningful software.

    There are different recent trends in software industry that try to tackle the issue:

    Agile software development tries to tackle this problem with practices like iterative development, integrating stakeholders and by embracing change with frequent inspection and adoption.

    Domain Driven Design (DDD) promotes the creation of an Ubiquitous Language and its realization in a domain model that reflects the business concepts in the implementation. The goal is to minimize translation between the domain language spoken by the business and the technical language the code is written in.

    Behavior Driven Development (BDD) promises to be a tool and methodology that fits perfectly for Agile software development and DDD in that it can support the creation of trust by shifting the focus of developers from implementation details to business value.


    Scott Bellware has some interesting quotes about this topic in episode 42 of Herding Code: Scott Bellware on BDD and Lean Development:
    [In BDD] what we try to do as programmers, is try to justify our worth by trying to communicate how much we know.
    The most value we have to business people is to stifle it everytime when we want to start talking about implementation details.
    The greatest confidence we can give to business people, is to let them know that we understand the business imperatives, that we understand what is at stake and that we are going to be committed to getting the problem solved. Starting to talk about implementation details is not gonna do it.
    We should commit to actually being business people. Its high time that we let go of the mystique of geek culture.


    1. Good post. Engineering steers away from being an isolated task.

      In a big telco company I've been working for, they try to achieve 'controlled trust' by totally isolating developers from business. This adds huge manager overhead, makes agile impossible and millions are spent for doomed projects. Basically this is anti-software engineering.
      Successful projects should involve business, engineering, marketing, users and designers in all decisions.

    2. Hi Jonas

      It's about trust, very true.

      However, I don't see the link to BDD and DDD. These are very technical things, the customer wouldn't want to know about.

      While they are great to build good software, the trust can be built only with communication (e.g. in the Scrum Review/Demo)


    3. @Urs

      Hi Urs,

      I agree that communication is the only way to establish and maintain trust with your stakeholders.

      TDD and DDD are certainly not a primary tool that can directly be leveraged to improve communication with your stakeholders.

      But I strongly believe that they are tools that aim at shifting the mindset of developers and therefore are enablers for better communication with the stakeholders.
      The stakeholders are never directly faced with DDD and BDD. But developers practicing DDD and BDD care more about business value and their daily language does ideally directly reflect the business... in such an environment communication with the stakeholders naturally improves!


    Related Posts Plugin for WordPress, Blogger...