Mark Twain once said he only has to do as much work as he has to. This quote has often been misinterpreted as one of an underachiever, a mantra for the lazy, bored, and burnt out. I disagree. In my opinion Mark Twain is a genius and can run all of my software development projects.

Software vs Sleep
Most projects are fraught with time wasters. Often, in our analysis and design process, we take special care to make sure everything is perfect - a very admirable trait. The only problem is that this takes an exorbitant amount of time and leads to such a strict specification, it needs to constantly be changed to reflect the ever-changing project environment. A more laid-back, flexible approach is in order. Call me a slacker, but it takes less time, is more flexible, and requires less rework. Don't get me wrong; it's important to participate in the early stages of a project. But it's also important to know when you can turn your spare time into sleep.

Logical Modeling
This can be the worst time waster. Early in any project the project's space-time reality is in flux. You may think that the requirements-gathering process is finished, but deep inside you know that any modeling will change as the scope of the project shifts. Most software engineers know this, so they don't put so much weight on concrete data models. This lesson is often lost on UML professionals who make a living building models. I could never quite understand why UML professionals aren't a bit more flexible in the early stages of a project. I can only come to one conclusion: UML people are evil. Remember that UML is used to help define a solution to a problem; to look at all actors, interfaces, and use-cases and then sketch out effective solutions. That's it. Unfortunately, some UML modelers think the project is to write nothing but UML diagrams. Here is an example conversation:

UML Developer 1: Your arrow is going the wrong way.
UML Developer 2: Is not.
UML Developer 1: Is too.
UML Developer 2: Is not.
UML Developer 1: Is too.

I'm tempted to send both of them to their rooms until they understand that the way the arrow is pointing will change a dozen times during the course of the project - so don't worry about it now. UML diagrams are about flexibility and understanding and should never be taken as gospel so early in any project. The goal of UML is to accelerate the development process, not become the development process. The reality of logical modeling is that it must remain very flexible - especially in the early stages of any fledgling system. When you hear UML people arguing, go take a nap. Neither of them is right anyway.

The Perfect Solution
In the logical modeling process, we often have a tendency to overanalyze. The military has an expression for this called "polishing the cannonball." It basically refers to spending so much time developing the optimal firing solution that the initiative is lost. We all want to do a good job. After all, looking thorough is one of the traits that have made us successful software engineers in the first place. But can you be too thorough? You bet. Recently I worked on a project in which a team of developers spent a day building detailed flowcharts on how a user would use a single data capture screen to insert one record into the database. Impressive, except to the person who has to pay for that time. A simple UML use-case diagram would have sufficed. It would say something like: "The user enters a record in the window and presses the ?Add' button. The data is then inserted into Oracle." It would have taken five minutes. After all, who is going to look at all those flowcharts anyway?

Over Normalization
This is one of my all-time favorites. How many of you have seen a gaggle of DBAs lock themselves in a room full of pizza and Jolt Cola (and who knows what else) to come up with the perfect normalized schema, only to have their egos shattered five minutes after emerging from self-imposed exile to enlighten the world about their misguided work? As it usually turns out, a perfectly normalized database almost never works in the real world. It's often sad to see the conversation:

Project Manager: Our queries require too many joins and are inexcusably slow.
DBA: But according to Kimball our architecture is congruent with (yada yada yada).
Project Manager: I don't care. Change it now.

Crushing conversation really. Database design should take into account that real-world issues will drive schema development. Next time you're invited to a DBA meeting, take a nap instead, unless you want some of that pizza.

Final Thoughts
Remember to focus on the deliverables. Most of the time, this is a fully tested, debugged, and documented system. It's the result of proper engineering processes, in the correct amount, at the right time. In reality each one of these processes is a vital piece of the puzzle. Great care must be exercised to make sure that these pieces fit snuggly together and do not wind up becoming the puzzle itself. There are only so many units of work that can be spent on a project. The role of the project leader is to make sure that only enough work is expended on each stage. Our slacker hero Mr. Twain would be proud.