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

August 31, 2009 | 3 Minute Read
This post was originally posted on my old blog.

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.