We just returned from our month-long vacation through New Zealand and Australia. What a trip ! The highlight in Sydney was seeing the beautiful Opera House

It’s really an architectural marvel. Such a beautiful design but was quite a construction feat. We took the tour and found out about the history of the building. There was a competition for the design and the design selected was really only a rough sketch. The shells of the competition entry were originally of undefined geometry, but early in the design process the “shells” were perceived as a series of parabolas supported by precast concrete ribs. However, engineers were unable to find an acceptable solution to constructing them.

From 1957 to 1963 the design team went through at least twelve iterations of the form of the shells trying to find an economically acceptable form (including schemes with parabolas, circular ribs and ellipsoids) before a workable solution was completed. Utzon came up with an idea of making all the shells of uniform curvature throughout in both directions which was called a eureka moment.

The idea was that the shells were developed according to a spherical geometry providing a common denominator, the same spherical surface to deal with, with a similar curvature throughout. This was an elegant solution to a construction, which would otherwise have had to be done with a large amount of scaffolding and shuttering, both for the interior and exterior shape of the shells. Now the shells could be sub-divided into ribs, which again could be divided into smaller elements, which could be cast within formwork representing the largest rib-entity. Thus it was possible to pre-cast the concrete-shells in smaller pieces and assemble these pieces on location. Because of the simple and consistent mathematical principles that were applied to the design, construction was both possible and much easier and simpler than it would have been if they had continued with the original parabolic concepts.

Software architecture also benefits from simplicity of design. A simple, uniform design reduces development time, improves maintainability, and makes modifications quicker and easier.

Often developers and software architects think they have an “elegant” design because they have tried to design very generically and/or very object-oriented, used a lot of open software components, and/or tried to plan for yet undefined requirements. But often the result is software that is much more complicated and bulky than needed. Over-designed, bulky software is costly to develop and maintain.

How can you tell if you truly have a good design or not? Here are the five keys to good software design:

1. Is there a simpler approach? In practice, the simplest approach is always the best. This goes against some software architect’s instincts when they feel they need to address unspecified requirements, but if the requirements are not stated yet, second guessing, if it adds complexity, should be avoided. If there are implementation strategies that are smart and brainy but overly complex, scrap those also. Keep it simple.
2. Is it customer-focused? Often design trade-offs are made that make the developer’s life easier but impact the customer negatively. If there is no benefit for the customer, the code should be removed. Less code is always better. (This does not include features that improve maintainability or delivery since they will affect the customer positively. But does include features or technology choices or functions that only make the life of the developer easier).
3. Is it designed for the expected user base? Often developers expect users to be as technically savvy or computer-adept as they are and inadvertently implement software that is not accepted by their user base. This was much of the cause of the downfall of Seibel – what the software did was great. The companies that implemented it though just couldn’t get their sales users to use it regularly. Hence the value of capturing important sales data was not realized. This is particularly true for software that users will need to pick up and use without the benefit of formal training classes. Or for users who don’t use the software very often but need to be able to just sign on and quickly get their job done. Or for users who have other limitations. Remember the old adage “Know your users” and take it to heart.
4. Was performance considered? From top to bottom, software design should always consider the end performance. Performance should be a factor in basic architecture principles as well as 3^rd party tool selection. Nothing impacts usability more than bad performance. Except bugs.
5. Is it reliable, maintainable, supportable? Quality: Clean, simple software tends to be more reliable because there’s less that can go wrong. In the software industry, often there’s complacency about bugs – some people think software always has bugs. Typically though bugs are a result of overly complex design, large/bulky architectures, which result in not enough test time. Simple, clean designs take less time to develop and less time to test. Installable/Upgradable: Especially for applications that need to be installed at a client site, the initial installation and ongoing conversions to the latest releases need to be quick and easy. Desktop software is often quite good at automatic installation and updates; but surprisingly enterprise application software typically needs to be hand-crafted and customized on-site. And each conversion to a newer release can cost companies millions of dollars. There is no real reason why enterprise application software should not be easily installed and upgraded. No customer-focused reason anyway. Although vendors do make more Services and Consulting money that way. Reliable: Most software nowadays, especially enterprise software, quickly becomes mission critical and companies who rely on it need it up and running 24 x 7. That means it must have high quality, be quickly upgradable, and be scalable to meet a company’s growing needs.

Good design separates clean, customer-acceptable software from gorilla software. Why is good software so hard to develop? Companies delivering clean, customer-focused software may not make millions in services fees, but some day (hopefully) customers will start pushing back on the software gorillas who charge millions for every major upgrade. When that happens, companies who know how to develop clean, simple software will be in high demand.

History of enterprise software according to Jan:

• 1970s – Large companies develop their own internal Manufacturing Resource Planning and Finance systems to meet their specific needs. Because these are one-off projects, the cost to continue to address new requirements is costly; many systems become out-of-date and/or costly to maintain.
• 1980’s – Software vendors begin delivering MRP and Finance solutions and some Legacy (internally built) systems are replaced.
• 1990’s – Software vendors combine various application solutions (MRP, Finance, HR, etc.) into one Enterprise Resource Planning (ERP) software package – one size fits all – and more Legacy systems are replaced. The ERP solutions try to address all automation for every industry with a single software offering. Thus the software requires huge customization efforts to meet each company’s needs; installation and upgrades costs increase. Specialized “Systems/Consulting” companies are formed solely for the purpose of installing, customizing, and upgrading the large platform software.
• 2000’s – Software vendors consolidate into a few mammoth gorilla vendors. Large software infrastructure layers are developed to integrate all of the various application pieces from the acquired companies into one single “platform”. Systems became even more complex; software costs for installation and maintenance continue to rise. A few smaller vertical-based vendors still provide clean simple software but competition with the gorillas is fierce. CIOs are convinced by the gorilla software vendors that enterprise software needs to be big and needs to sit on monolithic platforms in order to “integrate” and be “enterprise-worthy”. Yet few, if any, CIOs are able to realize the promise of easy integration using the big monolithic platforms, even if they stay with a single vendor. Implementations and upgrades take years and millions of dollars to complete.
• The Future – Companies reject the big vendor approaches. They refuse to pay millions of dollars for each installation and upgrade. Clean, simple software is demanded. The software industry evolves to meet the need.