The 3 Cs of Software Engineering

Is IT the same as ICT, only without “Communiation”? It might seem that way.

According to several studies software projects fail because of a lack of communication.

This why we need to apply the 3 Cs (Three Cees) of Software Engineering. With capitals, mind you. It’s a craft; you need to practise a lot. Writing software that impacts large parts of society is not a hobby! Y

It is most unfortunate that the sillabus for the craftsmanship that is called Software Engineering has so litte room for communication between humans.

(The short name for a software engineer is a developer).

The 3 Cs

1st C — Stakeholder vs. developer 
What problem needs to be solved?

2nd C — Team of developers vs. other Team of developers
How can we solve this problem together?

3rd C — Developer vs. developer
What are you doing and how can we work together?

Some clarification

1st C — Stakeholder vs. developer
In real life it can be pretty difficult to put on paper what problem needs to be solved.

Both parties always seem to know exactly what needs to be done; up until the first demo.

2nd C — Team of developers vs. other Team of developers
Larger systems (projects) require multiple teams to produce a working IT system.

Every team has its own goals, its own skillset and hence its own ideas on the ideal solution to the problem at hand.

3rd C — Developer vs. developer
If you’ve ever been or worked with a developer you will recognise this; two developers working side by side but none of them have a clue what the other is doeing.

What can we do about it?

Enhance communication!

There is multitude of things that can go wrong during the communication between two humans (yes, a developer is only human!). I’m not a psychologist, go read some books!

What can we do within a Software Project?
Ok, this I know a littlebit about. Mind you, I’m also a developer, so it might all be wrong; what do I know about other humans, right?

Apply an agile method
Nice refences are the Agile manifesto and the Scrum toolbox. I call it a toolbox because I’m not a methodologist.

Regular demo’s

A demo of the product will give the stakeholders an idea of what is build. If the stakeholders are allowed to ‘play’ with the demo, it might give them good insight in the design that should to be the solution to their problems. Not all stakeholders can read UML, Archimate or ER diagrams.

A demo will also force teammembers to deliver someting and it will force teams to synchronize their plannings. Delivering something that has to work good enough for a demo to the stakeholders will also kick of a whole chain of communicative events.

The stakeholders can used the demo to give feedback to the developers.

Use (industry) standards

Using a common reference models helps mutual understanding. Within IT this normally means the use of industry standards for the syntax (WSDL, JSON, XML, Swagger, etc). Standards for the semantics are harder. Think of a data dictionary that describes the common entities within a company.

Standards will not prevent miscommunications. The Arianne V was build using thousands of pages of standards. Nonetheless, it crashed.

However, using standards and increasing opportunities for communication will save on your budget for any IT project.

Like what you read? Give Marc Geelen a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.