In the previous post, we started to discuss a specific type of coupling, the coupling between processes in a distributed system. We discussed the fallacy that loose technical coupling, i.e., using a message-based communication style is sufficient to ensure loose coupling between processes. We learnt that instead we need to implement loose coupling at a technical and a functional level to actually become loosely coupled.

Coupling is a big issue in software design. With software landscapes becoming more and more complex, coupling painfully steps on our toes whenever we attempt to change things. Hence, we want to reduce coupling. On the other hand, without any coupling systems and their parts would not be able to interact. Hence, we need coupling – feels a bit like being stuck between a rock and a hard place.

In the previous post, we summed up the misconceptions we discussed in this series and what they mean for the current discussion if AI solutions will replace software developers.

In the previous post we have discussed that software is invisible which deprives humans from an essential reasoning instrument. We have also looked at the malleability curse, the property of software that it can be bent and twisted in totally absurd and nonsensical ways while still working in some way.

In the previous post, we discussed the value preservation dilemma of software. We have seen that software – opposed to almost all physical goods – needs to be changed and adapted to the ever-changing needs and demands of its environment to preserve its value.