After Hours

10 things a developer should never ignore

Whether you're a head-down developer in a large organization, a systems designer, or a single jack-of-all-trades for your own company, certain practices can help you produce a better end product. Veteran developer and project manager Bill Stronge explains some of most important things developers need to keep in mind.

During my years of developing applications, I learned that there are many do's and don'ts for approaching each project. If you're writing commercial code for a customer, you probably won't use it every day for the next five years. But even so, you need to take into account all the little decisions you make that affect not only application performance but maintainability, usability, and so on.

Here are some things I have discovered or that have been passed along to me by colleagues, which anyone who is developing applications should not overlook. By following some of these recommendations, you can help ensure you are producing the best quality product possible.

Note: This information is also available as a PDF download.

#1: Clarifying user requirements

As you spend more time developing an application, you can sometimes predict some of the requests of your customers. Don't take this for granted and assume you know more than your users do. When you receive the requirements, spend some time with them and review their specification to confirm you are on the same page. Not doing so can end up costing you time as you rework the application later on.

#2: Collaborating

Call it brainstorming, call it peer code review, call it whatever you want -- but just make sure you collaborate with those around you. Bouncing ideas off others will help you identify any holes in your potential solution and might even help you develop a solution better than your original design.

#3: Version control

Anybody who has ever had his or her code stepped on or deleted knows the value of a good version control system. It doesn't matter if its CVS, ClearCase, or even Visual Source Safe. Get it, learn it, and use it. You don't want all your hard work to be blown away with a few mistaken keystrokes.

#4: Basic system testing

Most developers don't like to test. Or maybe I should say most developers hate testing. But it's crucial for you to do your own testing before you release it to anybody else. Nothing will get your testing group upset and knocking on your door quicker than receiving code that doesn't perform the basics. Make sure entry screens allow input, check that you can't enter a letter where only numbers are allowed, verify that reports actually print information and that columns add up -- the basic stuff.

#5: Usability

Early in my career, I designed a screen for a group of data entry users. I thought my design was so slick. The system had all the bells and whistles they needed and then some. I was just about ready to install it when it was pointed out to me that the users almost never used a mouse. My design had added some buttons to the screen and had them lifting their hands from the keyboard over and over. Not efficient for them and very humbling for me. Spend some time to learn about the types of usability issues your customers may have and everybody will be happier.

#6: System performance

In this era of instant gratification, it's hard to satisfy end users. When they click on a button, they expect that the system will immediately respond. Or they may have the misconception that overnight processes really should take only an hour or two. When developing your application, ensure that you understand what type of response the users expect and require.

#7: Comments in your code

Comments are the bane of many developers' existence. We want to spend our time writing code not writing about code. But most of us have been tasked at some point with going in and maintaining somebody else's work. If you're like me, you may have sometimes found it so confusing that your first reaction was to rip it all out and start over. My experiences have taught me that even by adding some very basic commenting around sections of code and trying to use descriptive variable names and the like, you can have a significant positive impact on the next person who has to maintain your legacy.

#8: Logging

When you're developing applications (especially those without any type of user interface), make sure you build some helpful logging solutions into the code. There are few worse things for a developer to do than to try to debug an application with little visibility into what is going on when it is running.

It doesn't have to be overly complex. Maybe just writing out some of the values of your variables or counters at certain places in the code or when it hits certain subroutines. You can set it up so it logs only when a particular environmental condition exists (maybe a specific text file exists in a directory). Trapping anything that is going to help you track down and resolve issues quickly is what you're going for here.

#9: Keeping your skills up to date

Still coding in something a few years old? Many people work for companies run by legacy applications that are past their prime. But that doesn't mean you should ignore what's going on in the world around you. A lot of the new technologies out there can be integrated and could provide a boost to you and your company. Take some time to try to understand them a bit, and who knows when you can use it to your advantage.

#10: Taking pride in your work

One thing I always thought about and tried to pass along to my teams was the concept of having pride and ownership in the applications we were responsible for. I never wanted to hear that my applications weren't working at their peak capabilities or that users were unhappy. And if we did hear about a problem, we would go out of our way to do everything we could to rectify the situation immediately.

It doesn't matter if you are a head-down developer in a large organization, a systems designer, or a single jack-of-all-trades for your own company. Taking some of these ideas into consideration will not only help you produce a better end product but it will also allow you continue to evolve yourself and your career to the next level.


Bill Stronge is a PMP-certified project manager with a Global CPG organization currently focusing on eBusiness projects. During his 14+ years in the industry, he has worked on enterprise-wide applications in both a developer and architect role and as a project manager leading teams of various sizes. He can be reached for questions at wstronge@hotmail.com.

8 comments
Madsmaddad
Madsmaddad

And I don't mean the little bits that you want to add to the programs - the creeping excellence bits. I mean adding about 20% to the development time to allow for Holidays, sick days etc, so that you DO meet the deadline.

speculatrix
speculatrix

nice article - clear suggestions which are backed up by examples.

RonBeck62
RonBeck62

I enjoyed the article. It made many good points. Although trashing your UI instead of training the users on how to use tab and space to hit a button seems a little extreme. As long as you set the tab order(!) and don't have dozens of buttons to pick from, I don't think a few buttons on an otherwise mouseless form is a bad thing. I also got a chuckle out of "I never wanted to hear ... that users were happy"

Tony Hopkinson
Tony Hopkinson

#11 We'll never need to do this #12 Don't optimise something that doesn't work #13 Delete all protoypes #14 There's a reason that an assumption starts with stupid #15 Corners are where you get trapped, try not to deisgn yourself into one. #16 Shortcuts make for long delays.

brian
brian

Keep going Tony, I could read your list all day. Hilarious. So where do typos fit in? I have a blog on that... www.texttrustspellcheck.blogspot.com