Hello all,
For the benefit of new subscribers, and to refresh everyone’s memory: These days I’m exploring the difficulty a domain expert (e.g. a logistics professional) has to transfer his business knowledge to the programmer who is writing the software. I’ve already written two pieces about it. The main takeaway is that software consists of many parts, considerably more than a sword, a bridge, or a space shuttle.
In tangible items, you may need great skill in order to construct even a single part.
In software, the parts are mathematical concepts. Each part is generally much easier to construct. Have you ever written even a five-line program? There you are—you can construct a part although you are not a programmer. It doesn’t need much skill. In software, the skill consists in managing the complexity that arises from having a huge number of simple parts.
Until 20–30 years ago, we approached software projects as if they were bridges. We’d write a list of requirements, and a contractor would develop and deliver the software based on these requirements.
Today we know that this doesn’t work. One reason it doesn’t work is the complexity. We typically write software to assist business processes. The business process often has an incredible number of details, and we are often not conscious of their existence—they are the result of the domain expert’s experience. So you can’t really write requirements detailed enough, because you don’t know what to write—and even if you did, you can’t write something that detailed.
Today’s better methodologies consist in working together with the domain expert. For example, there’s a weekly or bi-weekly meeting where the programming team and the domain expert review the work done in the previous one or two weeks and set targets for the continuation.
However, there are some problems in adopting these new methodologies:
- Tradition and unwillingness to change on the software developers’ side. Some teams and companies have been around for decades. Some new ones got their experience in the old ones and they think that this is how it’s supposed to work.
- Likewise, on the domain experts’ side. One essential idea behind the “requirements” document is that it is a basis for a contract. What can the contract be if the subject matter is not defined in detail? Rather than find a way of co-operation that is suited to the new methodologies, we might only be willing to use the old methodologies because we can sign a traditional contract, which makes us feel at home.
- Fashion and trends. Just as today you’ll hear everyone say “we’re strategic“, when in fact they might be putting out fires all the time, you’ll also hear pretty much every software company say “we’re being agile” just because they use a tool that really agile companies also use. (“Agile” is the broad name of the new methodologies, but I don’t want to bother you with technical terms, especially ones that have become more of a slogan.)
Regards,
Antonis