Windows & .NET Watch: Quality: You are gonna need it

By Larry O'Brien

March 2, 2009 —

One of the guiding principles this past decade has been YAGNI: You Ain't Gonna’ Need It. YAGNI is a quick cure for the disease of Analysis Paralysis, whose symptoms include creeping scope, inactive version control systems and uncontrolled growth of class diagrams.

YAGNI does have side effects, however. Hyperyagnic Disorder results from abandoning too much structure and can be every bit as harmful as Analysis Paralysis. The disorder is characterized by brittleness of code, difficulty in understanding intent, and growth in the size, but not the number, of source code files. Consult your doctor if you experience a nested loop more than four levels deep.

Less flippantly, Analysis Paralysis and Hyperyagnic Disorder characterize too much and too little mental abstraction in the development process.

Software development is a game of balancing abstraction. Too much abstraction, and you find yourself reinventing e-mail. Too little abstraction, and you cram your entire system into a single webpage. The success of abstractions in code drives us to seek abstractions in our development processes; the unwavering demands of compilers drive us to think that we need to shut up and code. Over the course of a decade, common wisdom swings between one extreme and another.

There’s recently been a dustup among the twittering classes as to the proper amount of YAGNI. Joel Spolsky, CEO of Fog Creek Software, has advocated an extreme YAGNI stance, swiping along the way an over-reliance on unit tests and the so-called SOLID principles laid out by “Uncle Bob” Robert Martin. Spolsky dramatically overreached, claiming that those advocating high percentages of unit test coverage or promoting SOLID design principles had “not written a lot of code.”

Robert Martin has written a lot of code and needs no defense from me. On a personal level, each of the last three systems I've architected, while not particularly large, have gone from bogged down to shipped to transacting tens of millions of dollars per month. When I look at troubled teams today, I see Hyperyagnic Disorder far more than I see Analysis Paralysis. When I interview job applicants, Architecture Astronauts (as Spolsky labels them) are relatively rare compared to Cowboy Coders who are willing to abandon any semblance of discipline in the face of a looming deadline.

This is a change from a decade ago when, for a few years, the industry confused diagramming for programming. For several years, every programmer’s resume contained the keywords “Rational Rose." While Rational made fine products, this was like a racecar driver’s resume boasting they were skilled in "Chevy gas pedal." I was as guilty as anyone in overemphasizing diagrams, and I spent a silly amount of time taping together 16-page panoramic class diagrams and fine-tuning which diamonds were filled and which were unfilled. (On the other hand, certain diagrams, such as state-transition diagrams, are a lot easier to put together with a CASE tool than on a whiteboard, and, fashion be damned, I say that diagrams are often better than code for communication.)

Spolsky is an exceptionalist who argues that companies should seek out and retain great programmers, and that talented programmers should recognize that they need not work for merely average companies. While this works for him, it necessarily does not describe the average company or the decisions made by programmers about risk and stability in hard economic times. Spolsky is no slouch in the area of shipping software himself, and while I've never seen the code that drives FogBugz, I'm sure that it’s highly cohesive and has low coupling, even if it does not accord to the SOLID guidelines.

Exceptional programmers and teams don’t need to hew to any line, whether YAGNI or SOLID, when it comes to guidance. You aren’t an expert in something until you know three ways to misuse it. Bully for the expert teams at Fog Creek who can operate without resorting to checklists. But most of us do need guidance and easy-to-remember acronyms.

Spolsky’s own “Joel Test” of development team priorities is, in his own words, “sloppy” and “highly irresponsible.” It’s also excellent in its concept and brevity. In three minutes and 12 questions, you can get a very good sense of a team’s approach to software development. On the other hand, it believes that usability testing can be accomplished by grabbing the next five people who walk down the hall and forcing them “to try the code you just wrote.” In certain situations, that’s nonsensical (I have a client for whom information density is paramount to usability, even if it takes weeks to internalize the display).

When Spolsky attacks guidelines on object-oriented design or high levels of unit-test coverage, he is fighting yesterday’s war. This wouldn’t be worth harping on but for the fact that his arguments could lead to a YAGNI imbalance. Quality is the route to productivity. If you need productivity, you need quality. Quality can be improved with a balanced emphasis on code production, testing and design. You’re gonna need all those things.

Larry O'Brien is a technology consultant, analyst and writer. Read his blog at www.knowing.net.

Related Search Term(s): testing

Share this link: http://www.sdtimes.com/link/33303

Integration Watch: A new approach to testing: Crowdsourcing Gathering many testers together is uTest's model, and it is increasingly becoming a viable and sound option for developers

ThoughtWorks puts new twist on testing The latest release of this test automation software supports behavior-driven development and allows for common languages

Letters to the Editors: An alternative development testing method A reader points out a perceived flaw in functional and traditional testing methodologies, and posits his own technique

Comments

03/02/2009 06:37:47 PM EST

Larry, I love how you end this: "Quality is the route to productivity. If you need productivity, you need quality. Quality can be improved with a balanced emphasis on code production, testing and design. You’re gonna need all those things." We are rabid about code quality at NCOVER. Bad product sap the morale of the programmers who have to get involved to fix them. It just sucks. Here is one thing that we have noticed: Most developers don't want to write bad code; they just plan for any other option... DEW @danwaldo

United StatesDaniel Waldschmidt

Add comment

Name*
Email*
Country

Comment
Preview

News on Monday
more>>
SharePoint Tech Report
more>>

Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?

Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST