No Obvious Deficiencies: Quote of the Week

This is an oldie that I found way back when I was still in school...

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

C. A. R. Hoare

It is often our tendency as developers to make things more complicated than they need to be.  To counter that tendency, one of the Agile mantras is YAGNI (Ya Ain't Gonna Need It).  This is often hard to do because instead of designing and building huge frameworks up front, it means that as things are needed they have to be implemented or possibly current functionality has to be refactored to fit new features.  Very difficult for management, and often very difficult for developers!  "Just do it right the first time" is often the counter to this, but one of the difficulties is that "the right way" is often not clear until you've journeyed down the path a little bit.  And if you guessed wrong at the start and did not leave flexibility to choose a different path, it is harder to change then if you had waited.

Lean Software Development gurus, Tom and Mary Poppendieck, refer to this as "deferring commitment" until the "last responsible moment".  This doesn't mean that you hem and haw about things forever since usually that results in the "last responsible moment" passing you by which is as worrisome as making a decision too early.  (Mary gave an excellent Google Tech Talk on this principle called "Competing on the Basis of Speed" which I highly recommend.)

Like Goldilocks, we need to be in constant search of the approach, complexity and timing that are "just right".

Even simple requests become arduous to implement: Quote of the Week

This one is from Tim Barcz over at Devilicio.us.

A few weeks ago I got some evil glares when I suggested at our .NET user group meeting that in enterprise systems that you don't have time not to test. It's a common hurdle for those new to testing to say, "I don't have time to write tests." Let's face it, we're all busy, that excuse is tired. As an agile and lean practitioner I seek out ways to improve velocity and reduce waste, not take my already busy schedule and cram in another tool for the sake of another tool. While writing tests does slow me down, it brings on tortoise like speed, which I would argue is a good thing. Writing unit tests is one tool that provide me the ability to keep a more consistent velocity over the course of development. Without tests I can surely write things faster, the problem arises as the codebase grows and each new feature or fix takes increasingly more time. Eventually, even simple requests become arduous to implement. Slowly you see your velocity come to a crawl.

Tim Barcz

We're dealing with this very problem where I work now.  We reached the point where "even simple requests become arduous to implement".  But we are well aware of the traps that our predecessors fell into, one being that they gave up on unit testing under schedule pressure.  All that technical debt built up to the point that we are now declaring technical bankruptcy.

What does that mean?  Well, basically we're starting from scratch.  The original code wasn't built to be unit tested even though the original programmers wanted to do testing and even started to try.  But classes were highly coupled which made testing arduous.  And, unfortunately, instead of recognizing this as a smell, they pushed onward, declaring unit testing too complicated and time consuming.

So now it's our job to level out the graph and make the transition to a tortoise, pumping out a steady stream of reliable, well factored and unit tested code.

Egoless Programming: Quote of the Week

This is a hard one but an important one.  I found this quote on Jeff Atwood's Coding Horror blog on an old post that was referenced from a current one.  (It'll be nice to one day to be able to refer to myself as well as others in my own posts!)

Egoless programming occurs when a technical peer group uses frequent and often peer reviews to find defects in software under development. The objective is for everyone to find defects, including the author, not to prove the work product has no defects. People exchange work products to review, with the expectation that as authors, they will produce errors, and as reviewers, they will find errors. Everyone ends up learning from their own mistakes and other people's mistakes. That's why it's called egoless programming. My ego is not tied to my "perfect" or "imperfect" work product. My ego is only tied to my attempts to do the best job I know how, and to learn from my mistakes, not the initial result of my work.

Johanna Rothman

It's hard to sit there and watch your work get pulled apart and examined by somebody else and to take it and be constructive with it.  I know my first reaction is to throw up the defenses and start giving excuses or pushing that it's fine how it is.  BUT I do it because I know that it improves my code and improves my programming skills.

Great Ideas: Quote of the Week

It's interesting that sometimes think we know what we want, but we really want something else.  And in the space between the two is usually where the really great ideas are born.  When somebody discovers what we really want instead of continuing to give us what is we think we want.  Of course, this is a similar idea to the one discussed in the Innovator's Dilemma, another book on my "must read" list.

... many of the great ideas are not precipitated by the customer. While the customer knows what he wants, he doesn't always know what's possible. And that first dawned on me in my earliest days in business. When I was new at IBM, working in sales and taking a management training program in Sleepy Hollow, New York, I came back to my room grumbling about the lack of speed and reliability of the tape drives, and wondered why the engineers couldn't do something about it. My roommate stared at me with a look of total exasperation. "Boy, you guys in sales are all the same," he said. "You remind me of the farmer in 1850. If you asked him what he wanted, he would say he wanted a horse that was half as big and ate half as many oats and was twice as strong. And there would be no discussion of a tractor."

David Kearns, former CEO of Xerox

The Art of Programming: Quote of the Week

A good one from the Pragmatic Programmer guys...

The art of programming lies in that nether region between the hopeful wishes of an elegant architecture and the hard grindstone of technical details.

Andy Hunt and Dave Thomas

Ashton's Law: Quote of the Week

Alan Ashton is the man behind WordPerfect.

Ashton’s Law: Whenever someone tries to do something for you, they usually end up doing it to you.

Alan Ashton, 1974

Bruce Webster actually published the quote in his Remembering Ashton's Law post which gives a better understanding of what it really means...

For No Additional Cost: Quote of the Week

It's no secret that I love Peopleware.  Here's a little gem from it.  If you haven't read the book, I highly recommend it.

In most of the office space we encounter today, there is enough noise and interruption to make any serious thinking virtually impossible. More is the shame: Your people bring their brains with them every morning. They could put them to work for you at no additional cost if only there were a small measure of peace and quiet in the workplace.

Tom DeMarco and Timothy Lister in Peopleware (p 67-8)