Not All Gold Glitters

ooh, shiny

After two back-to-back posts, I thought I was done with YAGNI, simplicity, and economy of design – at least for a while. But then Jef Claes published “But I already wrote it”.

Jef’s post dealt with how a colleague had implemented a new feature in a much richer manner than anticipated. When the analyst confirmed that the implementation was more than what was needed, Jef recommended trimming out the extra, while his colleague argued that since it was done, it should be left as is. After pointing out the risks and costs of the additional complexity, Jef’s colleague came around (which is, in my opinion, the correct way to do YAGNI – a consideration of the costs and benefits, rather than a reflex). Then came the comments.

One commenter took exception to Jef’s statement that “code is just a means to an end; the side product of creating a solution or learning about a problem”. For that commenter, that attitude would “inevitably” lead to writing bad code. “The way you write good code is by loving good code”.

Another suggested that the situation taught his colleague never to take initiative and had ruined his/her job satisfaction. “From now on, he should consider himself to be a code monkey whose job is to accept the designer’s vision, regardless of how short-sighted or limited it is, and produce a working program.” This commenter stated that Jef should have waited to see if additional maintenance costs had materialized before deciding.

Needless to say, I disagree with both.

The first commenter above needs to understand that the application belongs to the customer. For functionality, substituting your judgment for the customer’s is unprofessional. If I ask for a garage and you build a mansion while my back’s turned, you don’t get paid. Taking pride in how you deliver value is a virtue provided that you remember that the customer is the one who determines what they value.

The second commenter assumes that Jef’s colleague will be discouraged because his initiative wasn’t accepted. If that’s the case, perhaps another line of work would be appropriate. As noted above, the customer determines what is needed and we should be taking pride in fulfilling those needs. They also assume that the design was short-sighted and limited, but the basis for that is never provided.

The second commenter’s suggestion that the code should have been left as is and only changed if a problem emerged is even more problematic. Taking on risk and potential expense on the customer’s behalf is not responsible behavior. Additionally, decisions are not made in a vacuum – each choice builds on earlier choices to enable or constrain (often both). Making those decisions without a rational basis is equally irresponsible.

On a personal level, I can sympathize that someone has expended effort and is proud of what they’ve accomplished. However, putting our own wants above the needs of our customers does not advance the profession. Delivering requested value, without surprises, does.

11 thoughts on “Not All Gold Glitters

  1. There’s even more pragmatic twist to that. Most likely, code is not the only aspect of project’s deliverable. More code automatically means more testing, both internal to the team and user acceptance. It also yields more to hand over to the user support function, more documentation to write and bigger ‘surface area’ for finding bugs later. Finally it increases the mass of the code base thus making it less agile for refactoring. All in all, doing more is even from purely process perspective is a sin.


  2. I agree with your conclusions but I respectfully disagree with some of your reasoning. Assuming the new code meets all the customer requirements (both specified and implied), there is nothing stopping someone from doing more work for the same price. If the customer asks for a garage and you build a mansion (including a garage) for the price of a garage, the customer may consider it a bargain, even if it is not their ideal mansion.

    Problems occur where either (1) focus is diverted away from the customer’s requirements when trying to do more, (2) significant technical debt is incurred with the additional work or (3) the additional cost of maintaining and testing the new features are not considered. A mansion may be great but if you have bulldozed their prized flowers, used “discount” building materials or not paid the increased property tax, you may end up in trouble.

    Therefore, violating YAGNI is a business decision (a consideration of costs and benefits as you say), not merely a technical one. That is why the “but I already wrote it argument” is so naive and why prototypes and emergent design must be managed carefully.

    As for “code [being] a means to an end” versus “good code”, they are orthogonal (unrelated). A garage may be a means to protect cars but just because the focus is on the car does not mean you build the garage out of mud, band aids and match sticks. Builders are still craftsmen.

    Indeed, (if I could continue the metaphor one last time) the meta-problem is that buildings have recognized minimum standards of construction (e.g. local building regulations). Without an equivalent, it is hard for developers and their management to know how “good” the code should be. Traditional development methods have tended to supply more features just in case. Newer methodologies, with which YAGNI is associated, tend to have fewer features but finding the right level is still as much an art as a science.


    • No worries, you’re pointing out things that I took for givens.

      A mansion in place of a garage would indeed be a bargain if I didn’t have to pay for the extra materials or labor, extra property tax, extra maintenance, etc. Essentially, I don’t see any gold-plating that doesn’t violate at least items 1 and 3 that you listed (and #2 is at least an even money bet).

      I definitely agree with what you said about “good code”. Conflating “my design” with “good code” is an ego issue. I definitely like the “builders are still craftsmen”.

      The minimum standards issue is a big one. I’ve had some tense negotiations with customers who wanted to cut corners (security, testing, etc.). Sometimes a compromise can be found provided that they’re fully aware of and take responsibility for any issues. Other times the best result is that they find someone else to work with. Either way, the important thing (IMO) is that the customer knows what will be delivered.

      Thanks for the comments!


  3. Dan North claims, and I grow to agree more with every passing day, that ALL software is a liability.
    Sometimes it is an acceptable liability (for example, a complex forecasting algorithm which will take many people to produce and still not meet the business deadline).
    Naturally, and line of code not needed is also a liability – one that you could happily live without.


    • This is a good point. Software is an expensive asset to obtain and even more expensive to own. The less you have of it, the better. Good software architects save trouble for their companies by reducing the amount of code written by developers, good enterprise architects — by reducing the number of systems the business relies on


  4. Pingback: Mixed Signals and Messed-Up Metrics | Form Follows Function

  5. This all sounds to me like the statement that computers have not been shown to increase productivity. As far as I can tell, the only innovation, ever, that has purely helped people is clean water supplies. Everything else is a mixed blessing.
    It seems funny to me that the most essential things are free or cheap – air, water, electricity, food – in that order, and the most expensive things are useless – diamonds, over-done housing, unnecessary boats, etc. If we had to pay for what air is worth to us, no one could afford to survive, or live long enough to earn it.
    Maybe we need some perspective: the most important thing is that everyone get a chance to develop themselves? What is that worth and what should we pay for it? This is why I have basically opted out of this culture: it is too stupid to learn. Eventually all the stuck people will die and something else will happen.


  6. Pingback: Who Needs Architects? Because YAGNI Doesn’t Scale | Form Follows Function

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.