I just read a blog post with a very intriguing question, “Do you code for humans?” I’d like to extend that question a little and ask if you should write code for management. On my job, (and I’m sure the same is true for many others) there is constant pressure to get it done and get it out the door. Little emphasis is placed on getting it refactored and getting the APIs extensible. In my work environment it’s very easy to get roped into writing code with half-baked APIs that are very specific to the problem domain, neglecting to establish any unit test prior to coding, and pushing the deploy button with little regard for ease of refactoring all the while preparing to counteract any request for change with a large estimate that reflects time necessary to pull apart the monstrousity you just unleashed on your miserable clients. After all you’re more than likely to feel heat for working in areas that appear to add no tangible benefit to your current project. So why waste time breaking that old 400+ line legacy object into a usable module especially since it calls for writing a complicated test harness prior the such a big change, a test harness which in itself would be triple the size of the beast you’re trying to test and would require the adoption of at least three technologies nobody on your team has even heard of? The question I’m asking is where do you draw the line between a reasonable deviation from your current project and a lifetime of chasing problem after problem when tickling one pice of existing code teeters a supporting beam of what is the fragile infrastructure of your application? If you’ve ever worked on a project like any of the applications I’ve been involved in then you’ll understand all to well what I’m saying. The problem is not that the itself is bad, rather it is the direction imposed by management, who has to tight a grip on development, that causes such pain.
So now I ask, should you write code for management or should you spend your next few years of employment fighting fires sparked by the radical new direction you decided to take. A radical, yet overdue, new series of design decisions that clashes with existing code like a prom shirt worn with blue jeans, sandals and a bubbled down filled winter coat on a hot summer day. What should a developer do in such a situation, when there is absolutely no hope in the existing design and direction, yet deadlines approach as constantly as the mile markers on the turnpike.What would you do when you know that your project, if written right, would involve a major change in the subsystem of the underlying application and you know that there is no possible way to explain such a requirement to management, who is of the belief that only a few tweaks are necessary to get it out the door? Would you appease management by applying the imagineary tweaks to peripheral logic or would you attack the real problem head on with absolutely no support or understanding from management? Do you write code for yourself, code that you can feel comfortable with maintaining? Do you write code for management in a desparate attempt to prove you can fit in with the “way of thinking” light-stepping as to not disturb the waters?
If you write code for management you know it will come back immediatelyas a change request which will require additional hacks that bloat your initial efforts ever slowing your development to a crawl and giving you the appearance of one who is not competent. Code written for management always leads to, “the end user is wrong” because their next decision will “break everything”. Code written for management always resembles that of a junior developer who appears to be struggling with the project because it’s harder to maintain than it was to develop initially. This kind of code makes your company look bad as well as management but it is apparently what management want isn’t it?
If you write code for you then it will immediately break everything because it will be the only piece of working code in a project that is inherently wrong by design. Code written for you appears to be self indulging code because it ignores the hundreds of existing APIs and modules and attempts to re-create the wheel. Code written for you takes you on an endless rabbit trail fixing things you have no business touching because, “the change was for sales and analysis modules not order entry!” Code written for you makes you look arrogant because it forces you to ignore advice and input from those put on Earth to assist you. Selfish code leaves you isolated when lonely when problems occur because you made decisions which nobody understood or saw the necessity for. Selfish code is also the most team rewarding code you can write as it adds value on each and every interaction with it.
What kind of code should you write? Are there any books on making such a tough decision? Are there books on writing selfish code? Holla’ at me…
(…hollering referrs to the act of obtaining one’s attention for the possible initiation of conversation. The request to holler at me is in no way intended to provoke arguments, flame wars, and/or non-constructive criticism.)