Yesterday there was an interesting article on InsideRIA titled: “How much is too much?”. This is a great topic, one which at times I have questioned myself.
Personally, I never take the “easy way out”, preferring to do things the “hard way”, so to speak. At times the benefits in doing things according to best practices, standards and conventions (a.k.a. “the right way”) may not always be immediately obvious. However over the years experience has taught me that in time the benefits always reveal themselves and the pros certainly outweigh the cons.
When given a good amount of forethought to a decision, a design an implementation and so forth a team almost certainly is afforded the ability to continue development feasibly and in a less challenging manner (as opposed to dealing with endless maintenance challenges). When things are done quickly with little regard for anything other than getting working code out the result is always failure at some level, most commonly the maintainability of a product.
With all this in mind it is important to understand that at the end of the day our development efforts, for better or for worse, are simply a means to an end for a specific business need. Therefore just as writing “quick and dirty” code has a negative impact on the business, so too does being a complete perfectionist. Admittedly, this used to be a challenge for me as I would tend to need designs, tests and code to “feel right” for them to be considered production ready, which typically resulted in me working many extra hours on my own time. This in itself is not necessarily a bad thing, but could rather be considered a labor of passion.
Ultimately the goal should be to find just the right balance of perfectionism, prudence and progress, providing necessary trade-offs where appropriate.
Not long ago Jeff Attwood posted about the subject. Check it out:
http://www.codinghorror.com/blog/archives/001230.html
I think we really need a balance between hitting the deadline and long term support. Experience plays a key role in taking such decision. Being able to recognize when something is worth expending some extra time with and when quick’n’dirty is enough is almost critical to developers, and definitely to technical leaders.
My $0.02 : )
Juan
Exactly, like everything in life, it is really all a matter of context, and knowing when and where to make trade-offs. Technical debt is as real as any other dept, and developers need always keep this in mind, most of us do. Perhaps one of the greatest qualities of a technical leader is the abilty to convey this to management.
Best,
Eric
I’ve noticed something interesting on this subject while working with various agencies. Developers who come from a design background tend to favour taking the quick’n’dirty route, while developers that come from a more traditional IT background tend to favour using best practices and doing things by the book. Why this is I don’t know, but one perhaps obvious answer is different interests at the core. A designer-developer typically has an eye for the visual parts, so they will be interested in getting things to look good quickly. A IT-developer (for lack of a better word) again care more about knowing that they used that one algorithm that is 2.7 times faster and only care about visuals once the app does what it’s supposed to.
The quick’n’dirty route has it’s advantages when working on e.g. campaign sites, which typically have a limited life span. The by-the-book route has advantages when you know the end result is long term and the maintenance cycle will be accordingly.
Personally, based on past experience I think the by-the-book route almost always is better, but like you and Zarate said, the real knowledge lies in knowing when to let it go and even more perhaps, having a nose for knowing if a project will be successfull and thus know if you should burn energy trying to convince management. I’ve been part of projects that were supposed to be short term campaign style things (with spaghetti code as a result), but turned out to be so succesfull that the client wanted to extend the life of the project. And then maintenance hell started because management at the start of the project only saw the short term goals and no one was able to convince them of the long term benefits of allowing for a couple of hours more to clean up the code. By doing at least a bit of by-the-book even on these projects, we would have had a much better place to start doing improvements once the decision was made to extend the life of the project.
btw. I just remembered a great rule of thumb from the book “Clean Code” by Robert C. Martin:
“Leave the campground cleaner than you found it” (you’ll notice this is a Boy Scout rule)
Translated to code speek it basically means you should always check in your code a little cleaner than when you started working on it. A little cleaner could simply mean e.g. changing a variable name to something more descriptive. The book, even though focused on Java development, has some great pointers that can be applied to any language. Highly recommended read.
Hey Jens,
Very interesting point. While I try to never stereo-type people with roles, indeed I have certainly experienced what you are mentioning in regards to some designers just trying to get things done with no regard for the future implications of their implementation decisions. However I have also worked with designers that were very adamant on doing things correctly and very open to learning new ways of doing things better. On the other hand I have worked with seasoned engineers, and perhaps more commonly IT managers, who have made some very questionable development decisions.
In any case, I never place blame on someone for making a bad decision if the decision was made honestly. More often than not bad development decisions are made with the good intentions. Most times developers typically just don’t know of a more appropriate solution.
I think ultimately it comes down to individuals, regardless of their role, or even their career. People make decisions. Some choose to do things correctly, and when they don’t know what the correct way is they take the time to research and discover what the right solution is. They strive for perfection regardless of what they have embarked on. While others may be completely content with just getting it done regardless of the solution.
In my opinion what makes a good developer is someone who always considers the implications of their decisions; be it in their design, implementation, conversation with a team member, manager, client and so forth. A good developer strives for perfection while also keeping a pragmatic approach to his/her decisions. This pragmatic approach entails not just being able to meet deadlines on time, on budget and with quality code, but also taking into account other variables such as team member skill set and so forth.
Best,
Eric
Hi Eric,
Good points and I’m totally on the same page with you regarding not blaming people for making wrong decisions in good faith. Something I need more experience in though is to tell when a person did a mistake in good faith, and when they’re simply being lazy. I want to support people who have a genuine interest in learning, but I’ve always hated leeches who just want you to hand them a solution. Unfortunately, my past experience is somewhat negative in this department so my initial reaction tends to be to think (not say): “read the f**king manual”.
I must admit I was, involuntarely, part of the “just get it done” crowd for quite some time back when I was starting out about five years ago. I always did things to the best of my ability then also, but due to the nature of the projects I was involved in I never had to think about how something would scale or what would happen if that one part needs to be changed in three months. It’s only more recently (say the last two years) where I’ve been involved in projects where I’ve had to open up my own old code and realized how bad it was sometimes.
But, like you hinted, being a good developer is also about understanding group dynamics. I used to sit next to a guy who when he got stuck always asked me if I remembered how one was supposed to do something. Sometimes these things were to me very trivial and core to the whole ActionScript language, so I started to wonder how he could not know this and had a negative reaction as soon as he leaned over to ask something. He used to call me a walking F1-key and for a while I though it was because deep down he knew he was using me because he was too lazy to look things up himself. Then I realized that he wasn’t being lazy by asking me all the time, he was actually being effective. If he had a small problem like remembering an API-call, he knew that there was a very high chance of me remembering it or at least being able to guide him to the correct section of the manual. Also, he was a very social guy who liked talking. So his first option was to ask me, because it was a lot faster for him than to browse through the API-docs. I on the other hand tend to always first grab the manual or do a search on the net before asking someone.
Once I realized this fundamental difference in how the two of us approached a problem I was able to start to “teach” him how I wanted him to interact with me, which was actually very simple. Whenever he asked a question, I acknowledged that he asked something, but then asked him to wait while I finished my thoughts on whatever I was working on. This could be ten seconds, it could be ten minutes. Then once I had a spot where I could take a break I asked him what his question was. This approach eventually led to a balance while still keeping the good spirit of the team, where he would no longer ask me the most trivial questions (because that might have cost him ten minutes instead of the ten seconds he was hoping for), and instead we could sparr on the more difficult issues where both of us would often learn something new.
The point in the above actually also comes back to why I appreciate blogs such as yours, where you don’t only discuss an issue from a pure “here’s a solution to this problem” point of view, but also take a more philosophical approach to the concept of coding. These types of open discussions give junior developers a window into the mind of more experienced people and hopefully that way also work sort of as a mentor substitute. For instance, one of the things I hope a junior developer gets out of the above is to look at issues from different angles. Not just within the code, but also try to think about how a designer or any other team member looks at a particular issue and that way, perhaps get a better understanding of why it is so important for the designer to move that one line 1px to the left or why that one developer always spends 5 minutes making sure his code is properly indented at the end of the day even though he just wrote it himself. Like you said, being pragmatic regarding other members of your team. A developer might think the designer is stupid for moaning about a 1px shift, but if he understands the designers definition of perfection, instead of moaning about him having to “change everything again” he might instead make sure he can make that 1px change more easily in the future, just in case the designer changes his mind.