Updated: 3/28/2005; 11:10:52 AM.
Mondegreen
Erik Neu's weblog. Focus on current news and political topics, and general-interest Information Technology topics. Some specific topics of interest: Words & Language, everyday economics, requirements engineering, extreme programming, Minnesota, bicycling, refactoring, traffic planning & analysis, Miles Davis, software useability, weblogs, nature vs. nurture, antibiotics, Social Security, tax policy, school choice, student tracking by ability, twins, short-track speed skating, table tennis, great sports stories, PBS, NPR, web search strategies, mortgage industry, mortgage-backed securities, MBTI, Myers-Briggs, Rensselaer Polytechnic Institute, RPI, Phi Sigma Kappa, digital video, nurtured heart.
        

Wednesday, April 09, 2003
trackback []

Martin Fowler in Refactoring: Here's a guideline Don Roberts gave me: The first time you do something, you just do it. The second tim you do something similar, you wince at the duplication, but you do the duplicate thing anyway. The third time you do something similar, you refactor.
9:36:46 PM    comment []
trackback []

From an interview with Martin Fowler: The cost of flexibility is complexity. Every time you put extra stuff into your code to make it more flexible, you are usually adding more complexity. If your guess about the flexibility needs of your software is correct, then you are ahead of the game. You've gained. But if you get it wrong, you've only added complexity that makes it more difficult to change your software. You're obviously not getting the payback. It's not hard to guess wrong about flexibility needs. You can guess wrong if requirements change. What you think is a requirement for flexibility now may go away or change in the future. You can also guess wrong if you put extra code into the program to improve flexibility but you don't get it quite right. You get more complexity without getting the flexibility you were after. …If you strive to keep your design as simple as possible by avoiding speculative flexibility, then it's easier to change the code because you have less complication to deal with. The code is easier to understand and easier to change. As a result, you can make changes much more quickly.

Absolutely. When contemplating the necessity of a feature or certain functionality, it is critical to consider not just the up-front cost of the original development, but also the lifelong cost of maintaining that functionality within the codebase. Every line of code added increases the complexity of the system. So, even if a feature could be added for “free”, it will come with a “complexity tax” that recurs for the life of the system. This phenomenon is a major contributor to sinking many projects before they ever go live, as well as to causing the shiny, new system to rather quickly degrade into the brittle, old legacy system that nobody really likes but can’t be fixed.


9:36:30 PM    comment []

© Copyright 2005 Erik Neu.
 
April 2003
Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30      
Mar   May


Click here to visit the Radio UserLand website.

Subscribe to "Mondegreen" in Radio UserLand.

Click to see the XML version of this web page.

Click here to send an email to the editor of this weblog.


Search My Blog