Tuesday, September 4, 2012

Sloppy Code is the Developer's Fault

This morning I arrived at work to see a TechRepublic article sitting in my inbox.

Sloppy code: Why it’s not (always) the developer’s fault

The author, Nick Heath, writes from the perspective of a program manager that displaces the blame for bad coding practices from the developer to the company.  He states that commercial pressures of the business is what drives developers to release code that is not of it's highest quality.  

I do believe that we (developers) are often asked to perform many tasks on very short schedules.  However, I consider myself to be a professional and sometimes (maybe too willing) to "stick to the man" and I'll speak my opinion of what the realistic expectancy should be.  I always provide my boss with an estimate and factor in 20% more time for issues that could arise.  Sometimes under certain conditions I'll provide multiple paths towards a goal, an optimal more scalable solution, and perhaps something that would work today and tomorrow but may not meet demands of future requirements.  In doing so I've come to be more respected by my peers for knowing when to say no.  I think as professional programmers we should realize that saying yes to everything is not the way to solve problems.

I think that Robert Martin says it best in his book, The Clean Coder - "Professionals speak truth to power.  Professionals have the courage to say no to their managers."  That's an important virtue for a developer.  Too many times are we asked to implement a new feature or a bug fix within certain time constraints, but its up to use to push back when those constraints are considered unreasonable.  Robert Martin goes on to say:
Slaves are not allowed to say no.  Laborers may be hesitant to say no.  But professionals are expected to say no.  Indeed, good managers crave someone who has the guts to say no.  It's the only way you can really get anything done.
When I worked at Total Quality Logistics (TQL) I had a software manager who always told his developers to "never say no" when it comes to a manager asking for something.  When I first started there I found that the temptation to be a "hero" and solve the problem was huge.  I got high regards for the person who could implement that application or feature quickly.  I enjoyed the bragging rights, but when I go back to review that code I see so many fallacies.  Some were obviously those of a novice coming straight out of college and others were just out of trying to get the feature done.  I know I learned a lot in those months of working there.  However, it was until later in my career when I slowed down on being the "hero" I found out that I learned so much more.  I learned the advantages of good coding standards, best security practices, and knowing when to say no to my boss.  Which lead to better quality programs that cost my employer less over time.
Mr. Heath writes: "Good engineers focus on engineering and sometimes lack the bigger picture to look at the business - [to realise] that if you don't ship this then we're going to bust," says Andrew Clymer.

If your company is in such a position that it could fail if your feature isn't released on time, then SO BE IT.  Do you really want to work for a company who's future strictly depends on your new feature?  If the feature is that urgent to the business then you'd expect that your boss has a lot riding on this and would want it to be reliable.
"Do; or do not.  There is no trying."  - Yoda
Now when I think back to that software manager at TQL I don't associate "never say no" to every request for a feature, but now I associate it with the possibility of the feature.  I think that makes me a better developer because I often hear from over developers "it can't be done" and dismiss it.  Now I assume it can be done, but how much time will it take me?

Thoughts or opinions?  Let me know what you have to say.

No comments:

Post a Comment