Writing software is so much more than writing code, at least if you’re on a small team.
When I graduated college, I quickly realized that I was not good at hardware design. I didn’t care about tweaking transistors for that last little bit of gain, and in fact wasn’t really sure the the right way to do it anyway. But I enjoyed writing software. I’d written little programs for about 10 years at that point. Usually I was my only “customer” and often it was just for fun. So I assumed that writing code is the same as writing software.
However, while I was at Caterpillar, I came to the realization that there is quite a bit more to writing software than just writing the code. We had an application that was used by our mechanics, and the mechanics at Caterpillar dealers. This was in the 2000-2005 time frame. You’d be hard pressed to find a better diesel mechanic than the guys we wrote for. You’d also be hard pressed to find more computer illiterate people. Fact of the matter was, they didn’t care about computers, they liked working on engines, and were very good at it.
Why does that matter? Because in 2003-4 when we wanted to upgrade the look of our program from a Windows 95 type application to something more like a Windows XP application we faced some opposition.
The tension was between programmers and users. Those of us on the programming side wanted to use some of the newer technology and do things from a more fresh perspective. However, our users didn’t want a big UI change. They knew exactly what button to click to get to the diagnostics page, and what menu items to follow to get to the throttle sensor calibration etc.
I see a lot of this going on today, as well. Perhaps more so. With the rise of applications like gmail and Facebook, developers have this urge to write code that is modern. Coders want to take advantage of jQuery, and make everything glassy. Which is fine for a commercial application.
In fact, you could argue that if you’re writing the next facebook application and you don’t use glassy icons etc you might not be well received. The general public expects things to be “white and shiny.”
However, if you’re writing an application for an internal user, you need to ask yourself some basic questions:
- Who will be the primary users of this application?
- What are the top three things they want to accomplish with this application?
- Is there an existing application that they use?
With this information, you’ll know what you need to spend your time and energy on.
If you’re writing a party planning application for college students, you’re going to want it to tie in with Facebook, Reddit, Twitter etc. You’ll want it to look Web 2.0ish (curved buttons and transparency etc.)
If you’re writing an application that will help an HVAC company get quotes on various HVAC parts, you’re going to want to ditch the popups, slide-ins and mouse-overs. They want to get their list put in as quickly as possible and generate a bill of materials. They know what a compressor looks like, they don’t need to see a representation of an AC unit with drag-and-drop components.
When writing business software, the actual coding is so often secondary. It’s understanding what your customer wants and needs, and writing software to help them reach that goal.