Comments on: It ain’t easy to be simple http://www.rubasch.com/2006/07/31/it-aint-easy-to-be-simple/ Daily Dose of Software Engineering Tue, 06 Jan 2009 15:36:02 +0000 http://wordpress.org/?v=2.0.3 by: Helmut Rubasch http://www.rubasch.com/2006/07/31/it-aint-easy-to-be-simple/#comment-4 Tue, 08 Aug 2006 20:34:24 +0000 http://www.rubasch.com/2006/07/31/it-aint-easy-to-be-simple/#comment-4 Very good point, Mario. <i>Simplicity</i> has to start way before implementation, design or even architectural planning takes place. It is already the phase of gathering and analysing requirements and planning the overall functionality of the system where a lot of emphasis should be put on making everything as <i>simple</i> as possible. You mentioned the problem that customers and developers live in two different worlds. The customer knows his domain and business and he knows which problem he wants solved (though he usually does not know <i>how</i> to solve it). The developers know <i>their</i> business, which in most cases has not much in common with their customer\'s. This commonly called <i>impedance mismatch</i> makes it difficult for these groups to communicate efficiently, which may be a reason why they usually <i>don\'t</i> communicate (another reason is of course that the customer cannot be expected to answer questions of hundreds of developers). Even bridging this gap with someone like a <i>business analyst</i> does not necessarily solve this problem. This person has to translate the problem from the customer\'s domain so that the developers understand it. He also translates questions from the developers and asks them to the customer. Aside from the rare case that this person is an expert in both domains, information loss is imminent. Enter <i>simplicity</i>. If the problem domain is <i>simplified</i> (or abstracted) as much as possible, the business analyst is much more likely to understand exactly what the customer wants. On the other hand it\'s much easier to convey the real problem to the developers without all of this white noise around. In a perfect world, the customers and developers might even use the same abstractions or metaphors for the same thing. Hey, in this perfect world they might even talk face to face with each other! Very good point, Mario. Simplicity has to start way before implementation, design or even architectural planning takes place.
It is already the phase of gathering and analysing requirements and planning the overall functionality of the system where a lot of emphasis should be put on making everything as simple as possible.
You mentioned the problem that customers and developers live in two different worlds. The customer knows his domain and business and he knows which problem he wants solved (though he usually does not know how to solve it). The developers know their business, which in most cases has not much in common with their customer\’s. This commonly called impedance mismatch makes it difficult for these groups to communicate efficiently, which may be a reason why they usually don\’t communicate (another reason is of course that the customer cannot be expected to answer questions of hundreds of developers).
Even bridging this gap with someone like a business analyst does not necessarily solve this problem. This person has to translate the problem from the customer\’s domain so that the developers understand it. He also translates questions from the developers and asks them to the customer. Aside from the rare case that this person is an expert in both domains, information loss is imminent.
Enter simplicity. If the problem domain is simplified (or abstracted) as much as possible, the business analyst is much more likely to understand exactly what the customer wants. On the other hand it\’s much easier to convey the real problem to the developers without all of this white noise around.
In a perfect world, the customers and developers might even use the same abstractions or metaphors for the same thing.
Hey, in this perfect world they might even talk face to face with each other!

]]> by: Mario Hochreiter http://www.rubasch.com/2006/07/31/it-aint-easy-to-be-simple/#comment-3 Sat, 05 Aug 2006 09:06:11 +0000 http://www.rubasch.com/2006/07/31/it-aint-easy-to-be-simple/#comment-3 Hi Heli! I agree with you that Software Engineering should follow the KISS principle and that software architecture and classes should be describable with a few words. Albert Einstein also said that people who do not have proper and deep understanding about the topic they are talking tend to complicate things. The problem in software engineering is that the customer mostly do not understand the topic he is speaking about. Also the complexity of requirements and user expectations have increased over the last years. This leads to the problem that the probability of failures increases due to size and complexity. Take Microsoft's Vista for example, the orignial requirements for Vista were to ambitious that even a company like Microsoft could not realize. I think to avoid or reduce complexity for an overall system is only possible in an isolated environment or with an adequate amount of time. The only possiblity in my opinion to reduce complexity is to invest a lot of time to define and priortize the requirements with the customer. As we all know this causes expenses nobody wants to pay. In most commercial projects the policy maker are economic people with no proper understanding in the field of software engineering. Furthermore, the software engineer mostly has no knowledge in the domain of the customer. Add the challenge of rapid ongoing change in the environment of software engineering. To compete this challenges i think you need a very motivated and talented team that gets support from business processes. Hi Heli!

I agree with you that Software Engineering should follow the KISS principle and that software architecture and classes should be describable with a few words.
Albert Einstein also said that people who do not have proper and deep understanding about the topic they are talking tend to complicate things. The problem in software engineering is that the customer mostly do not understand the topic he is speaking about. Also the complexity of requirements and user expectations have increased over the last years. This leads to the problem that the probability of failures increases due to size and complexity. Take Microsoft’s Vista for example, the orignial requirements for Vista were to ambitious that even a company like Microsoft could not realize.

I think to avoid or reduce complexity for an overall system is only possible in an isolated environment or with an adequate amount of time. The only possiblity in my opinion to reduce complexity is to invest a lot of time to define and priortize the requirements with the customer. As we all know this causes expenses nobody wants to pay. In most commercial projects the policy maker are economic people with no proper understanding in the field of software engineering. Furthermore, the software engineer mostly has no knowledge in the domain of the customer. Add the challenge of rapid ongoing change in the environment of software engineering. To compete this challenges i think you need a very motivated and talented team that gets support from business processes.

]]>