The Definition of Bad

| Posted on July 30th, 2015 by Sean Hopen

Sometimes you just want to flame out like Linus Torvald at a Microsoft meet-up, but not a good idea one-on-one, not with a client nor a co-worker.
Take a breath. Respect is all-important. Almost everyone on death row says, “I killed him because he disrespected me.” Think about that.

I don’t know if anyone here needs to be told this, but I thought this was a good how-to article, “How to address your coworkers bad code,” a kind of checklist to make sure you didn’t forget anything.

It also gave me pause to think about what is ‘bad’. Sure there’s just plain wrong, or smelly code. But the definition of ‘bad’ code could depend on the project, and to some extent the team.

When evaluating designs, libraries, and even the style of coding, for every project there are many different criteria: Time, cost, maintainability, compatibility, performance, security, robustness, reusability, and so on.

Setting the right levels on these parameters can be done explicitly for the project as a whole. Usually it’s defined implicitly as the team or company embodies a set of production values. Being explicit about your values can open up the range of solutions. So we don’t just code in one-style-fits-all. Defining your values helps with the cohesion of the team and ultimately the success of the project. A good team can nail the appropriate style, like seasoned studio musicians.

What about doing a quick discovery or requirements gathering phase to talk about the source code itself as a product? I often talk of the code as a user interface for future programmers. What are the requirements, the design values? Is there time for documents or thorough unit tests? Is it for beginners or experts? Is it quick and dirty for internal use, beautiful and exemplary for teaching, verbose to be completely self-explanatory? Is it rock-and-roll, a bit of jazz, or strictly ballroom?