Byron Kiourtzoglou

About Byron Kiourtzoglou

Byron is a master software engineer working in the IT and Telecom domains. He is always fascinated by SOA, middleware services and mobile development. Byron is co-founder and Executive Editor at Java Code Geeks.

Laws of Software Design

Software design just like any other engineering design endeavor, requires a fair amount of effort, experience, patience and knowhow in order to be done right.

Based on Akin’s Laws of Spacecraft Design I present our readers with a slightly modified list of what I believe are the basic “Laws of Software design” especially when you are dealing with customer oriented, “tailored” software product solutions.

As this is considered a “basic” list, let me clarify that you are more than welcome to contribute with you own experiences and comments on the matter. So lets start …

  1. Software design is done with numbers. Analysis without numbers is only an opinion.
  2. To design software products right takes an infinite amount of effort. This is why it’s a good idea to design them to operate when some things are wrong.
  3. Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time.
  4. Your best design efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment.
  5. (Miller’s Law) Three points determine a curve.
  6. (Mar’s Law) Everything is linear if plotted log-log with a fat magic marker.
  7. At the start of any design effort, the person who most wants to be team leader is least likely to be capable of it.
  8. In nature, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point.
  9. Not having all the information you need is never a satisfactory excuse for not starting the analysis.
  10. When in doubt, estimate. In an emergency, guess. But be sure to go back and clean up the mess when the real numbers come along.
  11. Sometimes, the fastest way to get to the end is to throw everything out and start over.
  12. There is never a single right solution. There are always multiple wrong ones, though.
  13. Design is based on requirements. There’s no justification for designing something one bit “better” than the requirements dictate.
  14. (Edison’s Law) “Better” is the enemy of “good”.
  15. (Shea’s Law) The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up.
  16. The previous people who did a similar analysis did not have a direct pipeline to the wisdom of the ages. There is therefore no reason to believe their analysis over yours. There is especially no reason to present their analysis as yours.
  17. Past experience is excellent for providing a reality check. Too much reality can doom an otherwise worthwhile design, though.
  18. The odds are greatly against you being immensely smarter than everyone else in the field. If your analysis says your terminal velocity is twice the speed of light, you may have invented warp drive, but the chances are a lot better that you’ve screwed up.
  19. A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately.
  20. (Larrabee’s Law) Half of everything you hear in a classroom is crap. Education is figuring out which half is which.
  21. When in doubt, document. (Documentation requirements will reach a maximum shortly after the termination of a program.)
  22. The schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it.
  23. It’s called a “Work Breakdown Structure” because the Work remaining will grow until you have a Breakdown, unless you enforce some Structure on it.
  24. (Bowden’s Law) Following a testing failure, it’s always possible to refine the analysis to show that you really had negative margins all along.
  25. (Montemerlo’s Law) Don’t do nuthin’ dumb.
  26. (Varsi’s Law) Schedules only move in one direction.
  27. (Heinlein’s Law) There ain’t no such thing as a free lunch.
  28. (von Tiesenhausen’s Law of Program Management) To get an accurate estimate of final program requirements, multiply the initial time estimates by pi, and slide the decimal point on the cost estimates one place to the right.
  29. (von Tiesenhausen’s Law of Engineering Design) If you want to have a maximum effect on the design of a new software system, learn to draw. Engineers always wind up designing the vehicle to look like the initial artist’s concept.
  30. (Mo’s Law of Evolutionary Development) You can’t get to the moon by climbing successively taller trees.
  31. (Atkin’s Law of Demonstrations) When the hardware is working perfectly, the really important visitors don’t show up.
  32. (Patton’s Law of Program Planning) A good plan violently executed now is better than a perfect plan next week.
  33. (Roosevelt’s Law of Task Planning) Do what you can, where you are, with what you have.
  34. (de Saint-Exupery’s Law of Design) A designer knows that he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.
  35. Any run-of-the-mill engineer can design something which is elegant. A good engineer designs systems to be efficient. A great engineer designs them to be effective.
  36. (Henshaw’s Law) One key to success in a mission is establishing clear lines of blame.
  37. Capabilities drive requirements, regardless of what the systems engineering textbooks say.
  38. Do not reinvent the wheel if you want to keep a new manned program affordable and on schedule.

Hope you liked it

Justin

Related Articles :

    Related Whitepaper:

    Software Architecture

    This guide will introduce you to the world of Software Architecture!

    This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.

    Get it Now!  

    Leave a Reply


    three + = 10



    Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use
    All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
    Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
    Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

    Sign up for our Newsletter

    15,153 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

    As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

    • Fresh trends
    • Cases and examples
    • Research and insights
    • Two complimentary e-books