Not too long ago, I was telling my uncle about an e-commerce site that a coworker and I were able to develop in about 4 months. I was shocked at his next query:

What is so hard about that? Why did it take so long?

What??? I write thousands of lines of code over dozens of pages, and you don’t get it? In a way, that means the software was successful. Often, the simpler the end result, the more code it takes to achieve that simplicity. Most users are completely oblivious to what it takes to create something that actually works.

Windows has over 50 million lines of code, which was written by over 5000 developers. I’ve heard that NASA spends over $10,000 per line of production code.

So why IS software so hard? It usually requires the entire mental ability of a software developer. In a given day, one would surely exercise their entire brain.

To write a feature, here is just a fraction of what must be considered:

• Software creation is art and science. You must be creative, imaginative, logical, talented, and knowledgeable.
• Layer synchronization – Data gets passed up and down between layers, and they all need to agree on how they will call other functionality, as well as how they need to be called. Decisions need also be made to determine if and where data will be validated.
• Failure modes must be considered – For every line of code, there needs to plan to handle that failure.
• Affected code needs to be evaluated – Ever heard the line "this is a small change, it won’t break anything". I’m not falling for that one again. It’s like changing out a block at the base of a pyramid.
• A testing strategy needs to be formulated – Unit tests need to test the new code, and acceptance tests need to test the new functionality
• More code must be maintained – Every line of code you write counts toward the theoretical maximum number of lines of code that you can realistically maintain.
• Consider performance and memory – The questions in this area are virtually endless, and the answers might not come easy. Compromise is inevitable.
• Technology considerations – How much does the target platform vary? What technologies will work, and which ones are the best?
• Balance modularity and simplicity – Sometimes they go hand in hand, sometimes they’re a tradeoff.
• Balance the needs of the present with the needs of the future – Try not to play the "What If?" game, but at the same time, don’t be ignorant of the future.
• Many companies have cross functional teams that developers must report to. Instead of having a manager that feeds a developer their work, now you have multiple sources that are asking for conflicting information. So much for a developer abstraction layer.
• You’re not the only developer – You need to be cooperative and collaborative to simplify the integration of your code.

Nothing is ever as simple as it seems. You’re not going to piece together code snippets from the web and create a great product.

Almost every time that someone shows me a snippet of their code, I hear a comment like this:

• "This isn’t finished, I have a lot of cleanup to do"
• "I wrote this code a long time ago, it’s not very good"
• "Ignore all these bugs, I haven’t had time to fix them yet"

We’ve all done it. It’s very rare that I hear a developer that is truly proud of their code.

So why aren’t you proud of your code? Part of the reason is that we often combine planning with writing code. I know that purists don’t like that, but the reality is that there are so many details in software that perfect planning is impossible.

The other reason is that we get our code working, and keep telling ourselves that we’ll go back and clean it up later. Then you tell yourself "why fix it if it isn’t broken?" You move on to the next task, and the cycle continues.

Common things that are overlooked:

• Proper exception handling and failure modes
• Properly disposing of unmanaged resources (IDisposable)
• Inefficient coding style
• Missing documentation
• Well thought out architecture
• Comprehensive unit tests & code coverage
• Following established coding standards
• Simplifying to minimize LoC to maintain

This post was inspired by a number of personal projects that I’m releasing as open source. I found myself doing a lot of cleanup work before uploading the source. I’m regretting not spending more time on it when I had written it.

So here is my challenge for you. Write code that you’re proud of! Do a personal code review before checking in your code. Then do a peer code review. If you’re embarrassed by the code you’ve written, go back and fix it. It’s commonly known that fixing the problems early on will have massive returns in the long run.

One of the biggest traps I’ve seen developers fall into is what I like to call the "What If" game:

• "Make your ID columns integers", "But what if we want them to contain a letter eventually?
• "Let’s cook these 10 steaks", "But what if 100 people show up?"
• "Let’s go to the park", "What if we get sick?"

The "what if" game consists of over thinking your plan. Planning in general is obviously essential. However, I’ve seen an alarming rate of crippling fear. Fear to write any code because it will never possibly handle all possible scenarios. It ends up being a self fulfilling prophecy of failure.

Sometimes the side effect isn’t just a fear to write code. It often leads to code that is generic beyond usefulness. For example, a database with all columns being VARCHAR(MAX).

Specialization is basically a spectrum. At one end, we have code that is so specialized that it is basically un-reusable. At the other end, the end I’m talking about, we have code that can be used everywhere, but doesn’t really do anything.

Some of the hardest decisions we have to make as developers are related to whether we base our decisions on the present, or a potential future that has a variable amount of certainty.

I’m not saying that you should avoid planning, but your decisions need to be based on the real likelihood that changes will need to be made later. An ounce of prevention is worth a pound of cure, but 64 ounces of prevention is certainly not worth a pound of cure!

In this post I’ll talk about a few ways that you can deal with the common influx of requests that come in for a software team.

I used to work for a large company affectionately known at the Borg. I was fortunate to work in a division of the company whose product was a software package. This essentially meant that I worked for a software company.

My current employer is a mid-sized business, and we’re not in the software business at all. My primary job function is writing custom software for certain customers, as well as creating the "glue" that holds together the software packages that we have purchased.

Luckily, we’re a growing company, so we’re starting to have a real software development team. With that comes with the pains of getting organized, and making sure we’re working on the right projects.

What do you do when the amount of work being requested from management greatly exceeds the amount of work your team can actually get done?

1. Push back – This doesn’t have to be negative. The person requesting a new software project might not understand that you’re team is busy. It’s common to think of an IT department as overhead. They are usually not factored into the costs of new projects. A good manager will be able to explain the situation, and either delay the request, or drop it completely.

2. Set up monthly meetings with the key management members - This gives people a forum where they must discuss the work they’re asking to be done. At this point, a good percentage of the work could disappear, because no one is willing to try to justify the importance of their project.

   Some of the projects that would normally be high priority are now not as important when compared relatively to all the work that needs to get done. This also gives management members time to negotiate directly with each other, and you won’t be caught in the middle of it.

3. Create a visible schedule of tasks that need to be done – When a member of management wants their work done, they can look at the schedule and see that they are not alone. If they want something done, they may have to negotiate with someone that is already on the schedule. If they can do that, they probably deserve to be on there.

4. Associate a cost with all work to complete – For any tasks that take longer than, say, 2 hours, require that the time be charged to a particular task. That time can then be equated with money. Since your time now has a set cost associated with it, people that need your time will have to pay for it. Actually money doesn’t have to be exchanged, but just associating costs will put the burden on the person requesting it. If they have to justify $100 worth of time to save $50, they might think twice.

Do you have any other tips for dealing with this situation?

What makes one developer better than another? Shouldn’t we all be performing at the same level? Of course not, we’re not sewing buttons on an assembly line. We’re using every bit of our intelligence to create something that we can only begin to understand.

• I think logically. Computers don’t care how you feel, and your opinion doesn’t matter. All that matters is if you write your code exactly the way the computer dictates.
• I constantly look for better ways of doing things. I subscribe to a good number of development blogs. I alone cannot always come up with the best way to solve a problem, but somebody somewhere probably can.
• I read books. Joel says that most programmers have stopped reading books. What a shame. Blogs are great for snippets, but it’s rare that they cover a topic well from start to finish. Blogs are the ADD version of books.
• I don’t stop thinking about problems and how to solve them through automation. Sometimes I’ll wake up in the middle of the night, and I can’t get back to sleep until I write some code that I can’t get out of my head.
• I have side projects that I think are interesting, and give me a chance to try things that I might not want to try on my production code at work. Yes, my side projects distract me at work, but the knowledge I gain pays back the time I lost.
• I have a tech blog. I suggest all developers start a blog and give back to the community. If you solve a problem, we want to hear about it! At the very least, it will give you an opportunity to formalize your ideas, which will either reinforce them, or make you realize you were wrong. You might also get some great feedback.
• I try to prove myself wrong (aka objective). Everyone wants to be right. I try to prove myself wrong when appropriate. One of the hardest things in the world for a developer to do is say that the code they just spent a week writing is useless. Maybe it is, don’t fight it, work with it.
• I keep up with the latest technologies, and force myself to try them.
• I have a relatively good understanding of how the computer hardware and software works. I’ve met too many developers that barely know how to turn on a computer.
• I’m great at writing Google queries.
• I’m not just in it for the money. I actually enjoy what I do. I had a job interview where the guy that would have been my boss told me a story about how he was brought in off the street and thrown into managing their software projects. When the software industry starts getting rough, who do you think is the first person to go?
• I’m sympathetic to the users pain. If I can share their pain, I’ll want to fix it and prevent it.
• I realize my code will never be perfect, so I try to make it testable and modular. I set up processes that try to minimize the effect of my human error.
• I don’t think Microsoft is evil, and I don’t think they’re a saint. They’re a big company. Some of the stuff they write is crap, some is amazing. The same is true for any other company out there.
• I learn from my mistakes. I try to put at least 2 checks in place to avoid any past mistakes. If one check fails, I’ll have the other.
• When I’m asked to solve a problem, I think above the problem, and determine if it’s a problem that even needs solved.