Lean Efficient Software - Less is Moore
When Developing Software and Systems Follow Chuck, Be as Lean as Possible
Why is developing software and designing systems expensive? It is because the Information Technology (IT) industry has failed to embrace the KISS principle (Keep it simple, stupid!). Computers, software and the tools to develop them has followed an upward complexity trajectory for many years. The complexity in software and systems really kicked in when the Graphical User Interface (GUI) became commonplace. All developers and designers in the computing field should look at the path followed by the pioneering engineer Charles Havice Moore, known as Chuck Moore. You could consider his family name and his design principles an oxymoron; for Moore his lifelong ideal is design less.
Lean, Mean Computing Machine
In the 1981 film Stripes the character of Ox, played by John Candy, has joined the army to lose weight and become a lean, mean fighting machine. Many systems suffer from bloatware and over-engineered software and would perform much better if they lost their complexity. Every year there are reports of multi-million, even multi-billion dollar, computing project failures, whether hardware or software, or both; complexity is often given as one of the reasons for failure. You can also look at the disappointment consumers often experience with electronic devices they buy. They are full of extraneous software and processes that eat processor cycles and computer memory causing poor interface response times and system crashes. Software and computer hardware has a bad reputation yet both are important areas of modern engineering, the modern world relies on computer systems. In some ways the move to agile development methods was a response to the increase in system complexity. A way to try and cap the ever increasing costs of developing modern systems. Yet Chuck Moore foresaw this early in his career and has always advocated the need to remove complexity from design; that way you still get a working system but you get it quicker and cheaper.
Beware the Ubergeek
In most computer projects there are key personnel who are largely responsible for the design, code and build of the system. These individuals tend to be very intelligent, work quickly and are highly productive. They are the company gurus or ubergeeks. The rest of the team usually act in a supporting role, implementing their decisions, doing the grunt work, fixing errors, running tests, shipping builds and authoring the documentation. Whilst organisations tend to rely on the ubergeek for most of there productivity there can be a downside that can cause long term maintenance problems. Problems that can affect the on going profitability of a project. If not carefully managed ubergeeks can over design with unnecessary complexity. In code this is often manifested as complex object orientated models, in hardware to much redundancy and to many components. They often cite reuse-ability as the argument for their designs, however, very few designs get reused again. Only the ubergeeks really understand the design and they are doing it because of their deep understanding of the tools and techniques being used. The rest of the team then struggle to understand the complex code and designs. The work they do on the system then gets criticized by the ubergeeks for not fitting in with the model they have built. This can lead to team discord. Further down the line, with the system delivered to the customer, the ubergeeks move on to their next project. They have no interest in their previous projects, they want to play with new tools and techniques. The project is in maintenance but with no one understanding the intricate design. This leads to patches to the system that adds further complexity, the code in the system becomes tangled and unstructured, becoming spaghetti code. The extra complexity often increases the cost for what should be small and inexpensive changes, reducing the forecasts for the profitability of the project, and if the margins are small, pushing it into loss making.
Keep It Simple Stupid
The only way to maintain project profitability is to rein in the design. That sometimes means questioning the actions of the ubergeeks and getting them to produce simpler models and straightforward code, they may be frustrated and even bored by this, if so their talents may be better employed elsewhere, e.g. research and development, and the project may require a more pragmatic programmer, just a geek instead of an ubergeek.
The less is more mantra applies equally to software development as much as it does to other areas of modern life. The phrase is taken from the 1855 poem Andrea del Sarto by Robert Browning. In the poem the painter Andrea Del Sarto laments his lack of ability to add depth to his work but praises his technical accuracy. However, it is technical accuracy (a crisp and clean design) that is the need in projects and no flourishes or extraneous additions, hence less is more. This principle was taken up in minimalist and modernist design in the 20th Century, and has existed in far eastern culture way before then due to the Taoist religious beliefs. This is exemplified in the rise of lean manufacturing in Japan where efficiency is maximized and waste minimized. The same lean concepts must be applied to systems engineering. When designing software and hardware only do what is necessary and no more, and do it with simple and straightforward code. No planning for reuse, just delivering to requirements and no more, because it is nearly always the case that those plans for reuse never match the new requirements that emerge. Whereas a simple and elegant design can be changed and adapted easily and quickly, often by those that are less skilled than the ubergeeks, and that is good for project profitability. So follow Chuck's mantra and remember that less is Moore.
Let's Finish with Steve Jobs on Simplicity
Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it's worth it in the end because once you get there, you can move mountains.
- Despite his extremely long and successful career, Chuck Moore started another venture in 2009 called GreenArrays Inc., GreenArrays develops highly efficient and highly parallel clockless microprocessors.
- Moving a team to lean and efficient agile development need not happen in one jump, see the article Waterfall or Agile? Do Both!
- An article on agile software development by app developers Fueled.
- For a full list of all the articles in Tek Eye see the full site alphabetical Index.
Author:Daniel S. Fowler Published: Updated: