Should you code for management?

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.)

6 thoughts on “Should you code for management?

  1. Hi, Cliff!

    Very interesting post, dude, but I mostly disagree. Writing code for management means finishing on time. Your manager, no matter what, is interested in finishing early or creating time buffers that can be spent dealing with bugs, fixes, planning and other tasks.

    If your manager has a false assuption – namely the assumption that the existing code is robust and stable – he’ll be happy to change it as long as it aligns with his interests.

    Coding for programmers is by no means selfish. Rebelling is selfish. It only works if you’re a 16-year-old punk girl. Like you said, it’s the most rewarding for the team, and it adds value all the time. I bet the whole hierarchy is interested in adding value to the product all the time. Especially the shareholders.

  2. Tiago,

    Thanx for taking the time to read my rubbish. (You’re one of the three or four readers I have.) I understand your position entirely. Let me further elaborate on where I’m coming from. Our team is tasked with re-writing a legacy Cobol app that was designed by management. Let me be more specific. My boss wrote the original system and now he is playing the role of both developer and manager of the rewrite. So it is rather difficult to change his false assumptions about rather large and ugly sections of code that desparately need refactoring in order to add new functionality. That’s the heart of what my post is about. In a perfect world management doesn’t try to program (or heavily influence programming) and the two teams can work in harmony. In my world I have to make the choice everyday, do I write code the way he expects or do I deviate and write it in such a way that it adds more value to the project. I call it selfish code when I write code that would wouldn’t have a problem maintaining because it feels selfish under these circumstances. That type of code sticks out as being the odd code and tends to be viewed as taking away from the project because it doesn’t mix well with “the vision”.

  3. Hi again!

    Now I understand what you mean by selfish code… well, I guess very few people can develop and manage the same project. Management involves painful decisions and requires a lot of letting go. I bet the folks higher up are very anxious.

    Maybe if you discuss “the vision” so that everyone agrees on where to bleed it? 🙂

  4. Tiago,

    I agree with you points. I tend to leave certain things out of my articles here because I don’t want to be too personal or look like I’m exposing people in a bad light. I’d rather focus on programming in general and leave personal issues aside, that is the point of my site here. The situation here has two sides and my boss does have very solid reasons for the approaches he takes. In short, there’s nothing wrong with his ideas or his approach. It just doesn’t mix well with the technologies and ideas we try to work with on the daily basis. It comes down to two different directions. We can continue the original direction and share “the vision” or we can do things radically different. I struggle trying to justify the radical new direction. I’ve had small successes and the boss listens. It’s just an uphill struggle that looks neverending.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s