If there's one thing that drives me mad, it's lazy developers. Unfortunately, most developers are lazy. I think one of the key attributes of an excellent developer is the fact they take the time to do things right instead of just hacking away at a problem until it seems to work.
Sometimes it seems that you just don't have time to do it right. When the deadline is fast approaching and your boss is breathing down your neck it's tempting to just get the damn thing working and out the door. "I'll clean it up later" you say. Yeah right, as if that's gonna happen. The problem with writing sloppy code is that it never gets cleaned up. People just keep adding to the pile making it progressively worse as time goes by. And by the time someone finally decides to make the effort to clean things up, they realise it's probably quicker and easier to just start over.
So what started off as a lazy bit of code has turned into a sloppy production application that is a nightmare to maintain and support. If only someone had taken the time to do it right the first time you wouldn't be in this mess. And here's the thing. Taking the time to do it right from the start is negligible. Taking the time to do it at the end is substantial.
But how do you avoid this situation that we all too often find ourselves in? Here is a list of things you can do to improve the way you write applications and stop yourself from getting into the mess in the first place.
Write a spec: Do you actually know what it is you're building? If you don't have a destination in mind, how do you know when you get there? Don't start coding without some kind of basic specification. It doesn't need to be long or fancy. It just needs to tell you what it is your building. Even if it's only a paragraph or two. If it clearly defines what you're setting out to do then that's fine.
Agree on the design: Didn't we just go though this? No, a design is different from a spec. A spec says what you're going to build. A design says how you're going to build it. Again, it doesn't need to be a fancy document with UML diagrams all over the place. It just needs to provide a high level overview of how you're going to write your code. It can be a single diagram, or a page of text or even a working framework. Whatever it is, just make sure that everyone understands it and adheres to it.
Use Source control: Do you have source control? If the answer is no, then stop everything immediately. You cannot build applications without source control. Period.
Write unit tests: Write unit tests first. Why? Because it makes you think. And that's something that many developers neglect to do before they start writing. Not only will it force you to think, but you have the added benefit that once you've written your unit test, it's always there to test your code for you.
Use a build script: You should be able to build and deploy your application in one step. And one step doesn't mean following an 8 page document explaining the step by step process to follow. One step means clicking a button or executing a script. A good build process will check out the latest copy of your code from source control, compile everything from scratch, run all your unit tests, build a distributable file (eg: an .ear file) and deploy the application to the appropriate environment. Getting all this up and running can be tricky, but make the effort, it's worth it. Not only will it make your life easier but it will make you much more productive.
Don't be lazy: This is the most important of all, don't be a lazy programmer. Take the time to do things right...
Write comments. Code is only written once, but you come back to read it time and time again. And when you do, it's helpful if there's a comment or two to explain what's going on. You're not going to remember what a program does in 6 months time when a bug crops up, so save yourself the time and effort and write comments now.
Don't hard code things that belong in properties files or in a database. It might be quicker for now, but what happens when that same program has to run in a development, test and production environment with different settings for each environment.
Write code that people can read. Compilers will optimize your code for you. There's no need to try and and be clever, especially when it makes your code difficult to read. And take a bit of pride in what you write. Don't leave auto generated comments lying around all over the place that say things like "To change this generated comment edit the template variable...". And don't leave print statements all over the place saying "##### Got to here - 17".
Refactor when needed. If you find yourself calling a method over and over again, perhaps it belongs in a utility class or in a super class that you can extend. Take the time to fix it. Don't just keep on avoiding the problem, hoping it will go away. My rule of thumb is that if I find myself calling or writing the same section of code twice, I seriously consider refactoring it. 3 times, and I definitely refactor it.
I could go on and on, but I think you get the idea. The most important aspect of all this is that it's not hard and it doesn't take much extra time or effort. In fact, you'll soon realise that it saves you time in the long run. But the benefits you'll gain from making these changes are huge. You'll be more productive, you'll be happier, and most importantly - you'll build a better end product.
So next time you fire up the editor to start coding, take a few minutes to think about what you're doing and find the best way to go about it. Don't just start hacking away, do it right the first time.