Sub-optimal algorithms and program code

Some argue that achieving better programmatic and resource use efficiency requires programmers to spend time working out ways to make their algorithms, and implementations of these, more efficient. However, programmer time is expensive, so there is a tendency towards expediency and putting out non-optimal program code because no-one is willing to spend the extra time (and thus money) on optimization, as long as the current code works, albeit sub-optimally. I agree with these sentiments and following is my view on the issue…

In my history working with developers, I’ve seen examples of expediting the code that did not meet the criteria, just to meet the deadlines. In fact, this is currently happening on the project I am currently involved in. Developers are constrained by the time given to them and tend to output quick solutions to user stories, that are later not accepted by the quality assurance team.

That’s the one end of the spectrum. On the other hand, I’ve also seen cases, where a programmer would endlessly keep altering and optimizing the code, just so it looks good and reflects positively on his/her work. This is also a problem because making something look good, many times doesn’t deliver any improvement to functionality. While it may save money in a long run, because the code may become more readable, in a short run it tends to cost more money and that is typically what business wants to avoid. Peter Seibel reflected on this in his book: ‘Coders at Work: Reflections on the Craft of Programming’: “It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products.” (Seibel, 2009)

I think most developers should strive to deliver code that is elegant, perfectly understandable, smart, clean, straightforward and maintainable.

But it there is no time, we should only make sure requirements are met and use duct tape if necessary so that we can deliver the code on time. And if a business wants to spend money on making the code gorgeous and efficient later, then the code can be refactored later.

However, our technical debt cannot lead us to the technical bankruptcy. That’s something we shouldn’t forget. So at the end of the day, we need to keep an eye on the issue and find the right balance between writing non-optimal code and spending too much time optimizing it.

At the end of the day, our job as software developers is to deliver a product that works, on time.

 

References

Do you actually write ‘clean code’? (2016) Available at: http://programmers.stackexchange.com/questions/29170/do-you-actually-write-clean-code (Accessed: 20 September 2016).

Seibel, P. (2009) Coders at work: Reflections on the craft of programming. Available at: https://books.google.ca/books?id=2kMIqdfyT8kC&pg=PA22&lpg=PA22&dq=%22At+the+end+of+the+day,+ship+the+fucking+thing!%22&source=bl&ots=Ml9rqfFDBD&sig=a8Sx5zkSbhXHWhPQRZdK2QjXB6k&hl=en&sa=X&redir_esc=y#v=onepage&q=%22At%20the%20end%20of%20the%20day%2C%20ship%20the%20fucking%20thing!%22&f=false (Accessed: 20 September 2016).

Technical debt (2016) in Wikipedia. Available at: https://en.wikipedia.org/wiki/Technical_debt (Accessed: 20 September 2016).

Comments

comments