If you're a software engineer, countless times you have been in situations where you had to choose between the easy way and the right way to solve a given problem.
Every experienced hacker knows that the right(eous) way will probably spare you some trouble in the long run (and probably will help you sleep at night too), but the same experienced engineer is also familiar with the reality of facts: sometimes there's just no time for best practices.
As a personal code of conduct, I think it is OK to choose the easy way (often referred to as a HACK) if the following is true:
- You are aware you are doing a horrible thing, and it makes you sick
- Environmental constraints (such as a guy coming at your desk every 5 minutes to check if it's done) make the HACK the only affordable/reasonable solution.
- You are aware that the given piece of
crapcode will most likely never be changed (we'll change it later = we'll forget everything about it around 6) - You can live with the fact that people looking at the horror will know you are responsible and talk shit about you when you leave (you can try to sweeten the pill with comments on how bad it is, but that just makes it worse)
In conclusion, as an engineer you are often called to compromise, and this is perfectly normal. I will add that this happens most of the times unless you are very lucky, and arguably as an engineer you'll be judged based on the goodness of the compromises you make.
Unfortunately, all of the above doesn't help with sleeping at night.
7 comments:
I like the idea of judging an engineer on the quality of his compromises.
When you build something real, you are always approximating mathematical perfection. Getting your hands dirty means exactly that.
I think a really skilled engineer would make a hack look elegant. When you give in to time constraint and hack don't throw all the best practices out the window. Single responsiblity. Small classes. Small methods. Use constantants. Make it clear its mocked data or hardcoded list which should come from the DB.
@Ian I do not disagree with any of that ;)
Most programmers, especially when working on a project, choose the fast way to do things vs the right way. It's not because they want to, it's because their project manager wants them to.
The problem here is that the project needs to be done as soon as possible - and compromising quality is one of the games that project managers play in order to finish the project on time. Of course, there is payback time for this strategy...
I think it has a lot to do with Management - if those on top don't care, why should anyone else? I insist my team do it right because it always turns out to be better in the long run. I can take the heat and deflect the brow beatings from upper management - that's what a good manager does.
At the same time, a good manager is deeply involved and makes the team think of all possible methods before making that decision of delay in order to do it right; i.e. it's very easy to argue delays and why you are doing something in a particular way when you have good, sound reasons. I never had a problem with this and I've been on the hot seat many times.
Thanks for your point of view Tim, insightful as usual :)
In general it comes a point where some decisions fall onto senior engineers and managers are unaware of the implementations details (or then again, sometimes you are your own manager!). Often you can get away with easy ways of doing things and no one will ever notice until there's a problem down the road. The only thing that keeps you straight is a sort of moral compass that, at least for me, is summarized by those questions I list in the post :)
Post a Comment