Maybe Means No

I would like to share with you a story. It is about a program manager (let’s call him Dave) who rose to that position, not because of his knowledge or expertise, but because he outlasted everyone else around him. His demeanor was very soothing. It was as though everyone around him was made to instantly fall into a deep hypnotic trance, such that any idea he may present, no matter how absurd, was instantly and unquestioningly accepted.

For example, the idea he conjured up for the design of a database. Or rather a modification to an existing enterprise database system that the company used for all of their accounting and billing. Now this database was an unwieldy and ferocious beast, lacking any sense or normalization or indexing. As a result, the reporting that was to be done every two weeks was arduous and brought the entire company to its knees. So Dave convinced those in a position to approve decisions that the best course of action was to create a new table that contained every field and record from every other table in the database. Yes, your read that correctly, replicate the entire database into a single table - to speed up reporting. And, it didn’t matter whether a field or record was currently being used for reporting, because one day it might be used.

As you code or design, if you find yourself using phrases such as “one day the client might want…” or “maybe the app should do…” or “the client could ask me to add…” or “we don’t use it today, but we might use this field one day”, then stop what you are doing because you are about to make a mistake. Designing with might, maybe, or could is one of the surest ways to introduce rot into your codebase.

Keep yourself out of trouble by following this simple rule - only add to a project when a business requirement or a unit test forces you to; maybe means no.