While we're on a motivational thread, here is, to my mind, a big no-no when it comes to business software ... the developer's ego.
It often seems to me that the only possible reason for some software features is to show off how darned clever the programmer is. I don't have any proof of this, it just seems that way.
OK, maybe a hint of proof in the way so many new features are touted on the basis of how cool they are, rather than any real benefit to the end user.
OK, mea culpa, I used to think that way too
As a hobbyist, it was absolutely the done thing to embellish games with gimmicks that would wow geeky onlookers. After all, why go for a simple drop down list when you could make a Town Crier character walk onto the screen and, with a theatrical flourish, unroll the list of options on a scroll?
While this kind of thing might cause a moment of entertainment first time around, believe me the novelty soon wears off when you are using the software day after day, and your focus is on completing a stack of work to a deadline.
Under those conditions, "cute" and "cool" quickly become grounds for keyboard-through-screen syndrome.
Tuesday, April 16, 2013
Monday, April 15, 2013
M is for Motivation
This year, for the A to Z Blogging Challenge I'm posting alphabetically on topics related to software development...
Last time, I talked about laziness as a personal motivation for doing a good job. Now I'm looking at another motivation for promoting good software that business should, but often don't, pay enough attention to.
Poor software costs money!
My department was building, module by module, an enterprise system. One of our departments had need of a system to manage electrical contracting work. We gave them a rough estimate for a simple system of $50k, which was basically our staff time at cost. This was in the days when that would get you a substantial amount of work for $50k.
"Too expensive," they said. A vendor dangled a baited hook in front of their eyes. They bit. "We can get a system that does everything we need for just $20k."
Long story short, the $20k soon ballooned into $100k once they took all the hardware into account, plus contract services to add in the bits that they needed that the system didn't do. And we spent the original $50k in our own time anyway, on interfaces to link them into the customer data and corporate billing system.
And the system still didn't work.
They spent months, and many sleepless nights in sheer frustration trying to get a problematic, bug-ridden system to do even the basics. They couldn't track work or invoice accurately. They lost business.
Eventually we had a window in our development schedule to help them out of this nightmare. Three months (and the promised $50k) later, they had a system that worked, integrated seamlessly, and did what they needed.
The difference?
We were motivated to tell the truth in the first place, and to do a good job.
The original vendor had no motivation to do either. Being economical with the truth got them the work in the first place, and they were only interested in screwing what they could out of the one-off installation, not in a long term business relationship.
Motivation, for good or for ill, is a powerful beast.
Last time, I talked about laziness as a personal motivation for doing a good job. Now I'm looking at another motivation for promoting good software that business should, but often don't, pay enough attention to.
Poor software costs money!
My department was building, module by module, an enterprise system. One of our departments had need of a system to manage electrical contracting work. We gave them a rough estimate for a simple system of $50k, which was basically our staff time at cost. This was in the days when that would get you a substantial amount of work for $50k.
"Too expensive," they said. A vendor dangled a baited hook in front of their eyes. They bit. "We can get a system that does everything we need for just $20k."
Long story short, the $20k soon ballooned into $100k once they took all the hardware into account, plus contract services to add in the bits that they needed that the system didn't do. And we spent the original $50k in our own time anyway, on interfaces to link them into the customer data and corporate billing system.
And the system still didn't work.
They spent months, and many sleepless nights in sheer frustration trying to get a problematic, bug-ridden system to do even the basics. They couldn't track work or invoice accurately. They lost business.
Eventually we had a window in our development schedule to help them out of this nightmare. Three months (and the promised $50k) later, they had a system that worked, integrated seamlessly, and did what they needed.
The difference?
We were motivated to tell the truth in the first place, and to do a good job.
The original vendor had no motivation to do either. Being economical with the truth got them the work in the first place, and they were only interested in screwing what they could out of the one-off installation, not in a long term business relationship.
Motivation, for good or for ill, is a powerful beast.
Saturday, April 13, 2013
L is for Laziness
© Photographer Remigiusz Oprzadek | Agency: Dreamstime.com
Laziness is a good thing.
Yes, you heard me.
And I stand by it, even after decrying laziness in other posts. The laziness I object to is lazy thinking, and short-term focus. The laziness that I support is long term laziness. And that takes a bit of effort up front.
I believe it's a good thing, because it motivates good design and quality work. I like building things. Once I finish something, I want to move on to something new. I don't want to be bogged down by old stuff. The best way to achieve that is to make sure whatever I build doesn't break five minutes later.
I guess this has been ingrained in me because I've spent my professional career in various in-house IT departments. Whatever I put out there is being used by my work colleagues, people I meet every day in the office. If I do a poor job, it comes back to haunt me. I can't escape it.
So this comes out as a strong will to make sure my work is useable, does the job it's meant to do, and will run as trouble-free as possible for as long as possible.
What's more, when the inevitable change requests come, they should be driven by new business needs rather than the need to fix something that isn't working quite right, and the code should be a pleasure to unwrap and modify.
Do it once, do it right.
Yes, the right kind of laziness is a good thing.
Friday, April 12, 2013
K is for Kindness
Whereas joy (yesterday's post) was an outcome, an effect rather than a cause, kindness is most emphatically a state of mind to be actively cultivated.
Be kind to your users
What does that mean?
More specifically, what does that mean in concrete terms in software design?
Let's start by eliminating a few suspects from our inquiries. For a start, I am assuming that the software does what it is supposed to do, i.e. it functions correctly. Also, I'm assuming that it performs well, and is secure and robust. That is not kindness, that is just doing your job. Take it as given.
But if it does all those things, what's left?
Consistency: When you are driving somewhere you've never been before, and you approach an intersection, do you panic, wondering how traffic is going to behave? No, you should know what to expect from the layout and the traffic signs. Road signs are consistent and traffic follows standard rules. All you have to worry about is which turn to take. The same should be true when a user comes to a screen or starts typing data. Completing a transaction should not mean clicking "OK" on one screen, hitting a "Save" icon on another, and a drop-down menu on a third. Clicking an "Exit" option should not save your work on three screens, but discard unsaved changed on the fourth. Be kind. Be consistent.
Comprehensibility: I wouldn't expect to drive around Victoria and find road signs written in Russian, or speed limits posted as fractions of the speed of light. Nor should your users be presented with instructions requiring a degree in astrophysics to understand. This is a business application you're writing. The only language that has any right to be shown is the business language that the user talks.
Clarity: Cluttered screens, scrolling windows within scrolling windows, nested layers of menu bars and ribbons ... space shuttle pilots might be able to cope. Not all of us are space shuttle pilots.
Tolerance: Kindness to your users means being tolerant of mistakes. A person should be able to hit a wrong key or click the wrong button, and be able to recover from the error. Many applications have an "Undo" feature, a good example of tolerance. But if you've finished a transaction and there's nothing to "undo", there should still be easy ways to correct mistakes, and to cancel or reverse entries.
Escape routes: Would you get away with designing a building without any means to escape a fire? Every step of the way through your application, there should be a way out. And, yes, it should be consistent.
Enterprise applications I've worked on in the past had a control or function key that unfailingly returned you to a menu.
The same key.
On every. Single. Damned. Screen.
Be kind to your users
What does that mean?
More specifically, what does that mean in concrete terms in software design?
Let's start by eliminating a few suspects from our inquiries. For a start, I am assuming that the software does what it is supposed to do, i.e. it functions correctly. Also, I'm assuming that it performs well, and is secure and robust. That is not kindness, that is just doing your job. Take it as given.
But if it does all those things, what's left?
Consistency: When you are driving somewhere you've never been before, and you approach an intersection, do you panic, wondering how traffic is going to behave? No, you should know what to expect from the layout and the traffic signs. Road signs are consistent and traffic follows standard rules. All you have to worry about is which turn to take. The same should be true when a user comes to a screen or starts typing data. Completing a transaction should not mean clicking "OK" on one screen, hitting a "Save" icon on another, and a drop-down menu on a third. Clicking an "Exit" option should not save your work on three screens, but discard unsaved changed on the fourth. Be kind. Be consistent.
Comprehensibility: I wouldn't expect to drive around Victoria and find road signs written in Russian, or speed limits posted as fractions of the speed of light. Nor should your users be presented with instructions requiring a degree in astrophysics to understand. This is a business application you're writing. The only language that has any right to be shown is the business language that the user talks.
Clarity: Cluttered screens, scrolling windows within scrolling windows, nested layers of menu bars and ribbons ... space shuttle pilots might be able to cope. Not all of us are space shuttle pilots.
Tolerance: Kindness to your users means being tolerant of mistakes. A person should be able to hit a wrong key or click the wrong button, and be able to recover from the error. Many applications have an "Undo" feature, a good example of tolerance. But if you've finished a transaction and there's nothing to "undo", there should still be easy ways to correct mistakes, and to cancel or reverse entries.
Escape routes: Would you get away with designing a building without any means to escape a fire? Every step of the way through your application, there should be a way out. And, yes, it should be consistent.
Enterprise applications I've worked on in the past had a control or function key that unfailingly returned you to a menu.
The same key.
On every. Single. Damned. Screen.
Thursday, April 11, 2013
J is for Joy
This year, for the A to Z Blogging Challenge I'm posting alphabetically on topics related to software development...
Most of these posts are about habits of thought. This one is different.
Joy in this context isn't meant to be a habit (although it helps to take joy in your work). I am suggesting it is a result to be aware of. A temperature gauge. A way to recognize success.
When you are doing a good job, a sense of joy should be a natural outcome. And when you have produced something truly useful and useable, something that helps people accomplish their goals - whether it is to produce that killer presentation, or get a customer's order delivered on time, or detect a million-dollar fraud in progress - people should enjoy using your software.
When you enjoy working on a product, and people enjoy using it, you know you are doing something right.
The converse is also true. If you find yourself reluctant to open up that code, if people groan every time they need to use your product, it's a warning sign to stop and take a hard look at what you are doing.
Most of these posts are about habits of thought. This one is different.
Joy in this context isn't meant to be a habit (although it helps to take joy in your work). I am suggesting it is a result to be aware of. A temperature gauge. A way to recognize success.
When you are doing a good job, a sense of joy should be a natural outcome. And when you have produced something truly useful and useable, something that helps people accomplish their goals - whether it is to produce that killer presentation, or get a customer's order delivered on time, or detect a million-dollar fraud in progress - people should enjoy using your software.
When you enjoy working on a product, and people enjoy using it, you know you are doing something right.
The converse is also true. If you find yourself reluctant to open up that code, if people groan every time they need to use your product, it's a warning sign to stop and take a hard look at what you are doing.
Wednesday, April 10, 2013
I is for Insulation
Old office buildings used to be designed much like homes: stone walls, plastered ceilings, wooden floorboards. Spaces to fill with furniture and people. Flexibility and change were not part of the plan.
That changed in the middle of the last century, with things like raised floors and suspended ceilings becoming the norm. This allows lighting, electrical, and telecomms services to be moved around to where they're needed. Office buildings also tend to be designed such that the internal walls are non-structural, so they can also be taken down and rebuilt easily without affecting the overall integrity of the building.
In this example, different parts of a building's function are insulated from each other, so that changes can be made to one element without affecting others.
The same thinking is useful in software. Different functions in an application should be insulated from each other.
This kind of insulation shows up in a number of techniques. Subroutines and modular programming were early examples, followed by message queues, client server, and object orientation. These are not mutually exclusive, just different tools to divide systems up in different ways.
To be effective, this kind of thinking has to be introduced early on in the design process, and like any tool you have to know how to use it. A poorly-designed object-oriented system can be just as much of a maintenance nightmare as early sixties spaghetti code.
Whatever the technique, the objectives of good insulation are pretty much the same. Each part of the system has its own special job to do and doesn't need to worry about how any other part works. This breaks the coding work down into bite-sized chunks, each with clear objectives. This not only makes the coding easier, it makes everything easier to test. It also means you can make changes to a function and be confident that your changes will not have unintended consequences elsewhere.
Imagine the chaos at home if the simple act of plugging in the vacuum cleaner caused the toilets to stop flushing. Laughable? Maybe, but that is pretty much the state many poorly-insulated software applications find themselves in.
That changed in the middle of the last century, with things like raised floors and suspended ceilings becoming the norm. This allows lighting, electrical, and telecomms services to be moved around to where they're needed. Office buildings also tend to be designed such that the internal walls are non-structural, so they can also be taken down and rebuilt easily without affecting the overall integrity of the building.
In this example, different parts of a building's function are insulated from each other, so that changes can be made to one element without affecting others.
The same thinking is useful in software. Different functions in an application should be insulated from each other.
This kind of insulation shows up in a number of techniques. Subroutines and modular programming were early examples, followed by message queues, client server, and object orientation. These are not mutually exclusive, just different tools to divide systems up in different ways.
To be effective, this kind of thinking has to be introduced early on in the design process, and like any tool you have to know how to use it. A poorly-designed object-oriented system can be just as much of a maintenance nightmare as early sixties spaghetti code.
Whatever the technique, the objectives of good insulation are pretty much the same. Each part of the system has its own special job to do and doesn't need to worry about how any other part works. This breaks the coding work down into bite-sized chunks, each with clear objectives. This not only makes the coding easier, it makes everything easier to test. It also means you can make changes to a function and be confident that your changes will not have unintended consequences elsewhere.
Imagine the chaos at home if the simple act of plugging in the vacuum cleaner caused the toilets to stop flushing. Laughable? Maybe, but that is pretty much the state many poorly-insulated software applications find themselves in.
Tuesday, April 9, 2013
H is for Help
© Photographer Razvan Oncescu | Agency: Dreamstime.com
An important businessman visiting Seattle was being whisked to important business meetings by private helicopter.
Mid flight, thick fog descended suddenly on the city. The pilot swore. Nothing was visible outside and his navigation instruments chose that moment to malfunction. He admitted that they were lost. He inched forward in the fog, until at last the lights of a tall building loomed ahead. Approaching closer, they could see people working in the building.
The businessman rummaged in his briefcase for paper and pen, and held up a sign in the helicopter window which read, "Where are we?"
Quick as a flash, a man in the nearby building held up a sign which said, "You are in a helicopter."
The businessman swore, but the pilot smiled, wheeled the craft around, and ten minutes later landed at their destination.
"We were lost," the businessman said. "How did you know where we were?"
"When I saw their sign," the pilot replied, "I knew we were at the Microsoft building. Their help was technically accurate, but completely useless."
Many help systems are really lists of technical reference topics. They assume you already know about the topics being discussed and just want some esoteric command or bit of syntax that you'd forgotten. In other words, they are no help unless you already know an awful lot about what you are trying to do.
Help needs to address many audiences, at different levels of expertise, and needs to answer more than the bread-and-butter "How to" type questions.
Sadly, the less-than-helpful variety proliferates because it is the easiest to write.
Make sure your help is helpful.
Subscribe to:
Posts (Atom)
Posts
