Quick And Dirty

Programmers write a lot of code. Some of it good, some bad, the rest just plain fugly. There’s code to provide functionality, code to prove a point, code to research a bug, code for fun; well, code for every occassion. So let’s examine the production occassion.

We’re employed to implement a feature and there’s a lot of code that needs to be written. But before we settle into implementation, we need to locate where it will belong. Like my cats kneading their sleeping spot, we refactor our bed of code to setup our work area. Then we settle into the business of production code. Red green refactor commit repeat.

Now when implementing “serious” code, we sometimes forget that QuickAndDirty code is just another tool in our box in order to get the job done. Faced with a lengthy workflow, there’s nothing wrong with plugging in un-cohesive, tightly coupled structs/procedures [ =:-o ] to get your thoughts down and documented. Of course, as with any tool, you need to use it correctly in order to get happy mileage out of it.

But just because you’re doing serious production code [and pair programming] don’t be too self conscious about the code you write. Be bold and get dirty. Write quick code to make it compile and flow. Just as red green refactor mantra is applied to tests; the same can be applied to production code.

The major advantage is that you don’t have to keep a hundred threads tied up in your head all at once while you journey through a workflow or a concept. Along each step of the way, there will be discoveries and unanswered questions about what [not] to do [particularly for UI based work]. These distractions can add up quickly and before you know it, you’re coding down a path that when you finish, it takes a while before you find that trail again.

Oh and by the way, don’t leave your tools lying around for others to trip on…


note: production code here is used to distinguish between purely test and deployed code, although i regard test code as production code in my environment.

Embracing Conflict

We all think differently, and this is a good thing. And there’s definitely value for particular paradigms at different points in software lifecycle. When we use the wrong paradigm at the wrong time, we end up in situations less desirable.

Researching the anti-patterns related to abstracting too early, it becomes obvious that implementing an abstraction ahead of its time results in bad design. Apart from the complexities and maintenance, there are hidden dangers about the assumptions subclasses make when they override methods, particularly over time and changing development teams. Couple these and you can end up with a time bomb.

This [abstracting too early] particular concept has resulted in endless [moot?] discussions within Agile teams debating inter-alia, upfront design, YAGNI and simplest thing. These “discussions” have divisive power and can hinder progress if the fruit of the discussions is not managed appropriately.

Yet, there are definite advantages to thinking this way. Thinking in the abstract and seeing a bigger and more vague, yet determined way, can be useful in spotting potential problems down the line. Thinking in the abstract and visualising complex inheritance heirarchies and patterns upfront [so complicated its bound to impress the client :)] adds value to the discussions and directions by adding scope to thought.

It becomes a problem when one argument insists, dogmatically, that the ObviousImplementation is the only road to take and the psychic team insist, equally vehemently, that it is the only road to take. And don’t think that a public opinion poll is going to substitute for real thought.

Regardless of the judgements ultimately placed on any pattern, or anti-pattern, methodology or approach, a successful team can work productively within the apparent chaos and all it’s contradictions. Deciding when to use which paradigm is a critical decision. Deciding to dogmatically ban one undesirable paradigm, largely because it surfaces at the wrong time, is a shortcut to weaknening your team and disempowering your colleagues.

At each end of the contradiction is a powerful force that needs to be maintained in tension with it’s opposite. By harnessing this tension you can maintain a steady and powerful course, but be willing and prepared to use the opposing powers when the balance shifts unexpectedly. The degrees to which you need to harness are determined by the degree of imbalance. And if you don’t proactively manage these forces against one another, they will ultimately clash and spiral into destruction.