“A professional system is one that can be supported in production easily. About the most unprofessional thing you can say is: “I have no idea what is going on”.
“While it’s a relatively rare occurrence, I absolutely hate having to say, “I don’t know what’s going on”. When there’s an odd error being thrown at a user who is trying to do something in our system it’s terribly frustrating to have to crack open the source code of the system to figure out why it’s being thrown.”
Sometimes a developer or organization will consider their code to be valuable. Is code valuable? I don’t think so. Code is a reusable and disposable resource. It’s also a liability.
Yes because when you write code and it solves a problem, it is useful. But once the problem changes, it’s just bytes. And believe me, the problem will change. Then you’ve got more bytes to maintain. Code then is a liability and the longer it sticks around the more drag you’re creating on the future.
What if you spent a non insignificant amount of time writing code only to discover the problem you were solving has changed? Well hopefully if you’re leveraging an agile methodology that time period will be small, but if it’s not you’ve got to be able to throw away your work entirely. It’s easy to get attached to code that you’ve written and want to try and take it along with you like a boat anchor but you must be able to dump your code without a second thought when it’s no longer useful.
Recognize when code is adding value and when it needs to be taken out back of the shed. It’s not your code. It’s the code. Make sure it isn’t a liability.
Software should be maintainable. Software should also be performant. Which is more important? Well, as it turns out, in order to optimize software for performance, it must be maintainable. Ease of change can easily be the most important factor in making something run well.
“In which everything is possible but nothing of interest is easy.”
– Alan J Perlis
Optimization up front often hinders evolution, because it’s designed to address a very specific concern without regard for future concerns. This is not to say that optimization is not important, it’s just something that should be done in such a way as to not hinder the ability to respond to change. Also, today’s compilers are a lot smarter than you are and can perform lots of optimizations themselves. Sometimes you simply aren’t smart enough to know where the bottlenecks occur, so it’s important to not optimize until you’ve actually proven via measurement where and why a performance issue occurs.
Programmers are really smart people, but unfortunately many programmers take pride in their ability to develop and understand complicated code. This is a danger that must be understood and avoided; particularly when it results in less maintainable code, or code in which only that single developer is capable of understanding and maintaining.
You Ain’t Gonna Need It. Resist the urge to optimize or implement functionality until it’s needed. This simple idea is actually the basis for much of agile software development. 90% of the functionality developed and shipped quickly is better than 100% of it shipped late or never. Why should you hold off on optimizing or implementing until it’s needed? The simple truth is that you don’t know what will be needed down the road, and so developing for it now will be a waste of time. Often times it turns out the code you prematurely wrote isn’t even needed, or your assumptions were wrong. So not only will you not need it, but even if you do, it won’t be in the right form that you are anticipating today.
Writing code that’s clear and explicit is better than writing code that’s clever. Programmers are really expensive, so it’s to your benefit to write code that optimizes for their time, and the way to do that is to write code that communicates to people, not the machine. Write the code so that it can be understood now and in the future with little or no additional explanation needed about how it works.
Everyone has probably seen Andy Hertzfeld’s story of Bill Atkinson during the development of MacPaint:
In early 1982, the Lisa software team was trying to buckle down for the big push to ship the software within the next six months. Some of the managers decided that it would be a good idea to track the progress of each individual engineer in terms of the amount of code that they wrote from week to week. They devised a form that each engineer was required to submit every Friday, which included a field for the number of lines of code that were written that week.
Bill Atkinson, the author of Quickdraw and the main user interface designer, who was by far the most important Lisa implementor, thought that lines of code was a silly measure of software productivity. He thought his goal was to write as small and fast a program as possible, and that the lines of code metric only encouraged writing sloppy, bloated, broken code.
He recently was working on optimizing Quickdraw’s region calculation machinery, and had completely rewritten the region engine using a simpler, more general algorithm which, after some tweaking, made region operations almost six times faster. As a by-product, the rewrite also saved around 2,000 lines of code.
He was just putting the finishing touches on the optimization when it was time to fill out the management form for the first time. When he got to the lines of code part, he thought about it for a second, and then wrote in the number: -2000.
I’m not sure how the managers reacted to that, but I do know that after a couple more weeks, they stopped asking Bill to fill out the form, and he gladly complied.
This is a great example to follow when considering YAGNI. Not only should you resist the urge to prematurely optimize or develop, you should also aggressively remove unused or unneeded code.
How do you protect your code base from complexity and premature optimization?
The only real solutions here are as follows:
I’ll end with the same quote everyone slathers around the web, because even though it’s repetition is common, it’s still true.
“Premature optimization is the root of all evil.” –Donald Knuth
Are you the sort of software developer that holes up in their office and rarely collaborates with others on work until your ready to cross the finish line? Or are you the sort of developer who actively involves others in your process?
Many software developers have the notion that if they work on something in isolation, they have the freedom and flexibility to define the process. We devs tend to feel like our way is the best way; You can see it when we inherit someone elses code, as our WTF-per-minute count spikes. However, if you’re always working under that model, you’re really missing out on your full potential. In my experience, here’s what you may be missing:
The Gold Plating Leash Handler
We love building castles in the clouds. It can sometimes be difficult to apply the YAGNI (You ain’t gonna need it) principal judiciously. It’s easy to be tempted to write code that is not necessary right now, because we’re trained to think about how our software might be used in the future. We love to refactor the hell out of code until it’s absoloutely perfect. We know that isn’t ever going to be true though. You need someone who can see the forest through the trees, or at least act as a reminder.
Two Eyes Are Better Than One
I would hope this one is obvious by now, but you must have a code review. By the very definition of humanity, we are imperfect, and therefor not having a your code reviewed is basically accepting that your code will fail to work properly at least some percentage of the time. Also, if you are humble and accept the fact that others will indeed have better ideas and perspectives (or at the very least, different perspectives than yours), you will be cognizant of the value others can add. In fact, I’d go so far as to say that there is a hard limit on the amount you can improve as a developer without outside perspectives and ideas.
The Squelch Filter
The stakeholder is always going to try and squeeze “just one more” feature/story in. The business is always going to wish you’d work faster, and for longer hours. You need someone to hold off the barrage of work that will come your way, the meetings, the last minute tasks, etc. You need someone to sift through the pile of work, pick out and prioritize it, and interface with you and the stakeholder in such a way as to maximize your productivity without exceeding the means that you are capable of.
In Summary
Working alone is fantastic. You wield complete control over the direction of your development process. But in the vacuum of your kingdom, you miss out on your fellow developers insights and knowledge assets. Don’t go it alone.