Homo technologicus' asylum

I often get criticized for my mantra towards the development approach. Your code may be elegant, by mine f***ing works. In response, I hear statements ranging anywhere from “You don’t understand best practices” to “You hate testing!” In an effort to avoid repeating myself on regular basis, I decided to write down my point of view on the topic. Adhere to it or not – your choice.

First of all, let me make a blanket statement here: the sentence “the project is late – but [it looks better/it is easier to maintain/the code is cleaner]” (pick any that apply) is inherently flawed. If the project is late – it’s not done. Period. There is no way to justify being late by using code quality/elegance as an argument. If the client needs a Christmas promotion, and you deliver a best product in a history of promotions on December 29th – it’s worthless.

Now, let’s address the “best practices” argument. I will keep using this phrase in quotes because the standards vary across the board, despite some common misconceptions, short of the most common Best Practices 101 that every programmer should have imprinted in their brain before the first “Hello World” is written. With that said, “best practices”, however you define it, should be a natural coding standard for any decent developer. If you need to bake more time into the project time-line to make your code comply – you are, at best, new to the programming scene. To trivialize the example, any seasoned programmer should instinctively know not to call the variables $a, $b, $c, etc., and properly indents the code lines. Granted, there are more advanced “best practices” standards that one might argue, but the point stands. And to expand on it, a veteran programmer knows when and, most importantly, how to cut corners, if needed, to meet the deadline. Which brings me to my next point – over-engineering.

I understand the desire to build the best, most flexible and robust system for every project worked on. I do. But I also understand the usual business constraints of every project: time and money. Most projects have a definite deadline and/or a specific budget that need to be met and, often times, building something grand is not feasible within either. This is where the developer needs to make a conscious decision to limit the creativity to meet the goals. There is no excuse to spend a week to setup a “proper” caching layer for the database queries operating on a 20-row table, that are only used from the administrative panel by three publishers. Understand the use-cases. And as cool as it may be to build a flexible and expendable XHR framework to support variable simultaneous requests; you don’t need to invest into it if the only feature that will be using it, is an update to a visitors counter on one page. Understand the scope. I cannot stress it enough – a good developer is not the one who knows how to build the most advanced system, a good developer is the one who knows when not to build that system.

In the world of software development, time to market is the driving force of the business. In a world of internet application development it’s even more apparent because of the dynamics of the web. The simplest solution is not often the best solution. It is always the best solution.

Perhaps the best analogy of my philosophy on the topic was made by my co-worker, when he heard my rant for the N-th time, by using a parkour reference. Assuming the goal of the competition is to get to the roof of the high-rise – some people will jump from balcony to balcony to get to the end, some will climb fire ladders, some will form a human pyramid. Me? I would take an elevator.