At a recent Pleasanton Chamber of Commerce meeting, the speaker, Keith A. Woods from the North Coast Builders Exchange, shared his thoughts on hiring secrets. He said the key to successful hiring was to hire people in the following order:

  • Smart and energetic
  • Smart and lazy
  • Dumb and lazy

and do all you can to avoid hiring people that are

  • Dumb and energetic

I liked this, but I would actually reverse the first two places and prefer to work with smart and lazy people—lazy in the sense that they like to be productive but not waste time. Energetic people often get carried away with being busy, without stopping to think whether they should be doing what they’re doing. Smart and lazy people will find ways to ensure that they are working smart. Here are my rules for being smart and lazy:

  1. If a job’s worth doing, it’s worth doing right the first time.
  2. Don’t do something just because you’ve always done it.
  3. Don’t do something today because you might need it tomorrow.

Do It Right the First Time

Smart and lazy people want to get a job done and not have to go back to it later. I’ve heard countless excuses for poor usability, out of date documentation, sloppy code, inefficient database design, lack of scalability, and on and on but it usually gets down to promising to do it right the next time. “We’ll get to it next release. For now, just do it quick and dirty. It’s good enough for now.” But quick and dirty is never quick in the long run! By the time “later” comes around, there are new functions to add, made all the more difficult to add by the squirrely code. The documentation was out of date to begin with and is now supposed to be caught up on the old while adding information about the new. The database design never gets changed and things live on and on that should never have been created. Each new set of functions that needs to be added makes more and more of a mess and takes longer than it should.

Let’s look at the classic deliverables.

go here gop amendment no viagra for sex offenders sildenafil pulmonary hypertension nejm comment acheter cialis sans ordonnance is 25mg of viagra dangerous ancient china introduction essay sample go viagra cannes 2009 china superpower essay contest college essay cultural development under delhi sultanate architecture here subaction showcomments propecia archive older follow site go here requip high risk drug comment utiliser une pilule de viagra follow url follow the story of an hour essay ideas go here inspiration from nature essay took too much cialis diosmin 30 comprimidos viagra a society of patriotic ladies analysis essay follow url is viagra used to treat bph Requirements and analysis: Do you know what you’re going to build? Do you know what problems you’re going to solve? Yes, things will change once the project is underway and things will need to be revisited in light of those changes, but that’s a bit different than not doing as complete and accurate a job as possible the first time. You need to find the balance between feeling like you have to define every little detail up front and defining enough to make an intelligent beginning.

Who are the users? Knowledge of the users is something that is most useful at the beginning of a project and continues right through to the end. Cut this knowledge out of the beginning of a project at your peril! Taking a wild guess in the beginning and plan on “fixing it later” means the business functions of the software are likely to be misunderstood and decisions about priorities of various features are likely to be wrong. You’ll be building the wrong thing from day one. Going back and adding an accurate description later means re-doing lots of other work or settling for it being done wrong. Smart and lazy people don’t want to go back and redo work so they will do the best they can up front. Smart and energetic people will create something that is reasonable, because they’re smart, but incomplete because they think they’ll fix it later. They like being busy so they don’t mind redoing work. Decisions based on those inaccuracies will be incorrect and will flow down the development process. And we all know what flows downhill.

What business problems is the software solving? This is pretty basic. If you don’t know why you are building the software, I think you’re pretty close to the “1,000 monkeys on typewriters writing Shakespeare” only your programmers pounding out the code will not turn out a masterpiece and will be very frustrated when they realize you didn’t even know what you were trying to build. Smart and lazy analysts will define things at the appropriate level of detail here—enough but not too much. They will look for the business problem that needs to be solved. Smart and energetic analysts are likely to go into way too much detail, trying to discover every little detail about current practices without realizing that merely duplicating existing business operations is not the way to good software.

The key here to me is that the smart and lazy person tries to answer these and other questions at the level of detail appropriate to their environment. The smart and energetic person may spend too much time, gather too many details, and get into that “paralysis by analysis” mode of operation.

Software development: The classic here is throwing together something meant as a proof of concept with sloppy code and little or no architectural considerations that then gets forced into being released product by “events”. Even more classic in terms of poor software development is to start here and skip the first step altogether! Someone has a cool idea for a tool. No market analysis is done. No potential users are identified. “We’ll throw it out there and see what sticks.” Working at one high-tech company that was feverishly releasing software almost daily to fix things that had been thrown together, I coined the phrase software du jour—it changed as regularly as the soup of the day at the local restaurant!

Business Models: Of all the evils perpetrated by the idea of “Internet time” this has done the worst damage in my opinion. By making it “easy” to change the software, people thought they didn’t need to think too much up front. Many managers touted the “low cost of change” based on the idea that their software wasn’t distributed or manufactured anymore so there was no penalty to changing your mind about what it is you were actually building. “Just throw the new version up on the Web”. I consulted for a company one month that changed their mission statement three times in that month! They didn’t know what business they were in; they didn’t know what market they were trying to sell to; they didn’t know who their users might be; they didn’t know how to make money off what they were doing. But boy did they think they had a cool tool! (And yes, they went out of business in the dot-bomb days.)

Don’t Do It Because Grandma Did It

Most of you have probably heard the old story about the newly married couple making pot roast. The wife cuts off the end of the roast and throws it away. The husband says “Why are you cutting off the end of the roast?” “Because that’s what my mother always did.” At the next family gathering, the husband says to his mother-in-law, “I’m curious as to why you cut the end off the pot roast.” The mother-in-law answers “Because that’s what my mother always did.” Grandma was at the gathering so the husband went over and asked her “Why do you cut the end off the pot roast?” Grandma looks up and says “Because my pan is too small!”

You need to know the cost and benefits of doing the things you are doing. Businesses change over time. Systems often do not. Smart and lazy people will be on the lookout for work that can be left undone with no harm. Smart and energetic people do the work and do it well, but they often do work that does not need to be done. Ask yourself what would happen if some document were dropped from your standard set. What if some meetings were dropped? What if fewer people were invited to the meetings so that decisions could be made more quickly and at less cost to the business?

Be aware of what you are doing out of habit! Be on the lookout for work that could be dropped to make room for more important work. Look for documentation that could be simplified, meetings that could be held a little less often. Don’t run your department based on the way Grandma did it without asking yourself if circumstances have changed to the point that things should be done differently. (Be aware that, like the old Lonzo and Oscar song, you’re usually your own Grandma! Most of us can easily see other people’s work that can be simplified, but not our own beloved processes.)

YAGNI – You Ain’t Gonna Need It

Smart and energetic people believe “Never put off till tomorrow what you can do today.” Smart and lazy people say “Never do today what you can put off till tomorrow!” This is, to me, one of the most useful tenets from the eXtreme Programming movement. At first glance, it may seem the same as Rule #1, but it’s very different. Don’t build today what you might need tomorrow. Odds are you will not need it tomorrow and you will have wasted the effort. When you try to see too far into the future, you get the opposite of “paralysis by analysis”. It quickly becomes paralysis by over-design. The requirements become bigger than they need to be, the code becomes bigger than it needs to be, the testing and documentation take longer than they should, the maintenance is more of a headache—all because you built what you didn’t need today! Of the ten things you build in and design and document and test because you might need them one day, one or two may actually be needed in the future. But you’ve put all that work up-front to make sure that you can do all ten things, thereby wasting 80-90% of that effort. Eliminate that wasted effort and put the energy where it’s needed. Smart and energetic people seem to like too look far into the future. They see features and functions that may be useful tomorrow as being absolutely essential to define and build today.

Are you designing a system that may one day need to use Canadian zip codes but today only needs to handle US ones? YAGNI says build it to handle US ones today and add the Canadian capability when the time actually comes that you need it. The smart and energetic people think they’re being smart and lazy because they say “Look, if we add this to the database now, we won’t need to muck around with the database later. So put in all these extra fields and constraints so we don’t have to do it later.” At first glance this might look like something a smart and lazy person would say as part of Rule #1! But the smart and lazy person says “Why do it today if we can put it off till tomorrow? Besides, we all know the database is going to change no matter we put in today. Maybe we’ll need to handle zip codes from other countries later, too. So let’s resign ourselves to the fact that we will need to change the database in the future. And to make tomorrow’s changes as simple as possible, build only what we need today. Then when we need some of the extra fields, we have less work to do to work them in.” Rock-solid plans change; laws change; users change; technology changes; business models change. Any one of those changes can severely impact what is needed by the time tomorrow comes.

Database design seems to be one of the more common examples of this I run into. In the worst example I saw, database tables were being created for a new set of applications that would need to have a one-way data exchange with an existing 3rd party application. The original “import” from the 3rd party application simply included all the data fields—regardless if these fields were empty (having never been used for the past 15 years) or if they were needed by the new system. Five years later, 60% of these large fixed-size text fields have never been used in any queries by the new system, but they exist in every row of the huge table, are backed up regularly, and have been documented countless times. And every new programmer eventually learns they can be ignored.

Obviously, YAGNI works for all areas of software development. Do you need that document today? If you need it later, create it later. If you end up not needing it, you’ve saved time and money. Do you need that project plan to go 5 years into the future today at that level of detail? If the detail is not useful (or likely accurate), strip it out and leave high level items in there as a general road map without the detail. (Sort of like “In 5 years we’ll want to be in Montana and today we’re in California. Let’s start by heading north because we have to be in Oregon next year and after that we’ll turn east!” No interstate plans. No hotel reservations. And you certainly don’t need to plan where you’re eating dinner on the 300th day into the trip!)

In summary,

  • If you’re going to do it, do it right.
  • Think about whether you need to do something or not
  • If you won’t need it till later, don’t do it now.