Three Flaws in Software Design

In below Google Tech Talk series - "Jeremy Walker" & "Max Kanat-Alexander" discussed the three Flaws of Software Design, from Max’s book Code Simplicity: The Fundamentals of Software.

• Three Flaws in Software Design – Part 1: Writing Code that isn’t Needed
• Three Flaws in Software Design – Part 2: Not Making the Code Easy to Change
• Three Flaws in Software Design – Part 3: Being Too Generic

I enjoyed to attend their 40 minutes of talk and below are notes taken for quick reference, but I would strongly suggest to attend this tech talk series for better understand by examples.

Overall software design can benefit incredibly, if such fundamental flaws are avoided.

Flaw 1:Writing Code that isn’t Needed (16 minutes video)

• Sounds like "YAGNI" but it's more.
• It's not about whether you're going to need it in the future.
• It's about good design.
• Maybe the only way to do good design is to need the code. (Software solves real problems)
• Problem
• Bit rot
• Will need to be redesigned
• Trying to handle "every possible thing"
• Not really saving you time
• Adding complexity
• Can be whole classes or functions that you don't need, but sometimes just lines of code you don't need.
• RULE
• Don't write code until you actually need it, and remove any code that isn't being used.
• During code review, check that do you really need this code now for given requirement?
• Avoid… avoid… avoid… DEAD CODE.
• Don't assume requirements and write unnecessary code. Ask lots of questions to clarify requirements and write simpler code.

Flaw 2:Not Making the Code Easy to Change (12 minutes video)

• Also called Rigid design. Two ways to accomplish this,
• Design in too many assumptions about the future
• Writing code without enough design
• Too many assumptions
• For futures with waterfall model - Essentially a failure to understand that requirements will change.
• Code can be done in small ways too - For example (i) using magic numbers instead of constants (ii) if you don't need to support international users in current requirements, then you may just consider adding support of it in design as a future requirement but don't implement across the whole framework.
• Code without enough design (Spaghetti)
• May be even say to some degree - the more you assume things won't change, the more your code becomes spaghetti.
• Spaghetti is hard to change because of - Duplication, Complexity, Safety, Could possibly also inversely define spaghetti by these traits
• RULE
• Don't assume too much for future requirements. Code should be designed based on what you know now (based on factual requirements), not on what you think will happen in the future!
• The quality level of your design should be proportional to the length of future time in which your system will continue to help people.

Flaw 3:Being Too Generic (10 minutes video)

• Often called over-engineering.
• You cannot accommodate every future requirement now.
• Too much effort for too little value.
• Developers do this all the time by trying to be "good" when they don't need to be:
• Catching exceptions that don't need to be caught
• Expecting input that you never get
• Handling situations you're never in (like multi-threading)
• Injecting dependencies when there's only one choice
• "One day we might need to…"
• RULE
• Be only as generic as you know you need to be right now. Never duplicate code. Have a stable and simple design.

Also Refer

• OOP Design - Fundamentals and Principles