An idea I have thought about for a while now is the concept of the “lazy programmer” and how they are better than a not-so-lazy or overly enthusiastic and energetic programmer. I am being a bit disingenuous, though, because saying “lazy” is a bit inflammatory. I will stand up and say I am doing that quite deliberately, for a specific effect. I actually have a definition in mind of what a “lazy programmer” is, as well as what this type of person is not.
First, I’m not talking about lazy in the traditional sense of someone who doesn’t want to do any work, or puts off delivery and deadlines. When I mean “lazy”, what I actually mean is someone who only builds what is necessary, anticipates a small number of things that the requirements do not. However, they do not gold plate the end result with features and functions that weren’t asked for or aren’t needed. A “lazy programmer” will still work hard. They may still have to work long hours. But, they are lazy only in that they don’t do anything extraneous. I believe that this type of “lazy programmer” is a core tenet of agile development.
Perhaps a better definition would be a “minimalist programmer”, but that has other implications, and sounds a bit pretentious. Personally, I like to see the look of shock on people’s faces when you say “I’m a lazy programmer” and they have visions of someone arriving late, leaving early, and napping at their keyboard for most of the day.
In any software project, from a simple utility or program written by one person, to a large distributed system that requires a larger team of programmers, testers and operations staff, building to requirements can be hard enough. Harder still is when the requirements change, both in direction or in scope. By adding your own “feature creep” and building in features no one asked for, you run the risk of destabilizing the end product because there is now code that may or may not get run, and may or may not get tested. It makes it harder for QA. This is because they either have more to test when they know about these extra features, or they don’t test them at all because they don’t know they are there. This then filters down to operations and support, who again either have to be aware of the feature (and perhaps know to avoid it), or don’t know about it, trip over it, and cause problems for themselves or your customers.
A lazy programmer won’t add new features that either aren’t requested and aren’t needed. If the requirements call for it, and you’ve agreed to the requirements, then I believe you have committed to write to them. However, there are times when you will see holes, and you may have to expand the requirements to fill the holes you have noticed. The trick for a lazy programmer is to only fill the hole up as much as required, and no more. In some cases, the customer may have deliberately agreed to a gap in functionality: a lazy programmer will simply work around that gap for now, and worry about filling it in later.
These lazy programmers will still pay attention to the details, and still follow best practices and processes for developing software. They are still diligent in their own testing, and are responsible enough to use good code analysis and testing tools as part of their job. They still ensure that their work is reviewed by others, and is testable both programmatically and manually by QA. They may be “lazy” but they aren’t sloppy.
So, to my mind, the lazy programmer is the one you want. I believe that their work results in better quality, less rework, less downtime and a more satisfactory experience for everyone involved.