There are always going to be scenarios in a piece of software that the developers haven't thought of, causing serious issues in the application. Sometimes these issues can be caused by faulty software, but they can also be caused by corrupt data, corrupt files, problems with the operating system, etc. If one of these issues causes the application to crash, it is generally called an unhandled exception.
Unhandled exceptions can make software users nervous about the quality of their software, and so software developers rightly try to avoid them. This idea can be taken too far, though. I have worked on a few applications where the developers involved tried to avoid showing the user an unhandled exception at all costs. However, that meant that there were times when something went wrong, the error was swallowed by the software, and the user was never notified. This can often result in messy data. To see why, consider this scenario:
A doctor at a hospital is entering her patient's medication information in the computer to monitor the patient's medication types and amounts to prevent over-dosage and dangerous drug interactions. This patient has just been administered three drugs. In entering the information, the application has unforeseen problems with medication #2. If the error allows the application to crash, the doctor will know that something has gone wrong and will restart the application to see what information will need to be reentered. This is annoying for the doctor, but is not life-threatening. If instead the application had swallowed the exception, and either gave the doctor a cryptic message or no message at all (which is sadly often the case), the doctor will have no idea to go into the system and double-check those entries. I can only imagine the problems that can be caused by incorrect medication information being stored for a patient.
So what does this mean for you? If you are on the implementation side, do not give into the temptation to bubble-wrap your application to the point where unhandled exceptions can never occur. Certainly handle the exceptions you can foresee. Your users will rightly expect this. But do not hide problems to the extent that no one can tell they occurred, or that the user does not understand the severity of the error. Finally, be sure that you are notified through an automatic e-mail or similar measure if such an error arises. If you are a user, do not overreact when such an error occurs to you. It is certainly frustrating to have your software application quit on you, but keep the alternative in mind. At least you know something went badly wrong.
Saturday, September 18, 2010
Sunday, September 12, 2010
What business people need to know about software development
Claiming ignorance of information technology in this day and age is just like claiming ignorance of accounting. Every manager must have a basic knowledge of IT just like they must be able to read a balance sheet. Determining what, exactly, every manager must know is difficult, though. Like most things, it depends on the context. I'll start with what business stakeholders need to know about software development, in large part because this is my specialty.
Basic Terminology:
User Interface - This is the term for the way in which the software user interacts with the application
Database - This is software that stores the data in most scenarios
Server - This is a computer, usually with a large amount of memory, that hosts the software or database
Hardware - This refers to the physical components of a computer
RAM - Think of this like short-term memory in humans: it stores information that might be needed in a few minutes, but does not hold information in the long-term
Refactoring - The process of rewriting working code to make it more readable
Data - Another name for "information", though "data" is plural
Development Process:
Writing software does not follow a predictable method or process. If it did, we could write software that could write software for us and save everyone a lot of time and money. (Most good programmers will do that when and where it is appropriate.) Because software writing is a highly creative and unpredictable process, nailing down solid estimates can be tough. If you try to force your developers to stick to their original time and cost estimates, you will likely create a contentious atmosphere which will get in everyone's way when trying to get work done. Instead be flexible to estimate changes. If it looks like a task or component is taking too long to complete, decide if it is worth completing after all. If so, keep in mind that the next estimate very well might be too large and you'll be even in the long run. If not, it is better to stop a time-consuming task early to avoid throwing good money after bad.
Early detection of problems is important
If you notice something strange in your application, especially if your data looks wrong or missing, find out what the cause is soon. Chances are that there's something wrong with your user interface and your data is fine, but if there's something in the application that's corrupting the data the sooner you can find the problem the easier it can be corrected. Lost data can be recovered from backups, but most companies only keep backups for a certain period of time.
Early detection is also important for problems like software slowness. If your software is slow, it is not likely going to speed up on its own, and will likely get worse over time. Fixing the problem early before complaints start coming in will save both you and your developer time and frustration.
Know what will change in your business requirements...and what won't
Many developers would disagree with me on this one, but I think it's important to communicate which of your business requirements will never change and which ones will certainly change over time. For example, if you have an e-commerce site that sells shirts, you might expect to add colors to your offerings, but you will not likely add sizes. The reason for this is that most developers will program non-changing requirements differently than ones that will change often. The non-changing requirements can be coded in such a way to make it easier and faster to write the first time, but harder to change going forward. The opposite is true for the changing requirements. This concept isn't critical, but it is something to keep in mind.
When problems arise, adding more bodies is probably not the solution
If a software project falls behind schedule, resist the urge to request additional resources to get it done. Why? Since, as I mentioned before, software writing is a relatively complex process, it will take time to get new resources up-to-speed on the specific requirements of your project. This not only means that these new resources will not be as effective as your current ones, but your current resources will be less effective than they were as they help bring the new resources into the project. Your best bet is probably to adjust your expected finish dates. If that is not possible, then adjusting the number of features to be added should be the next option.
Know the general limitations of your approach
I am not suggesting that you become a programming expert by any means, but you should be aware of the limitations of the software delivery method you choose. For instance, applications for a hand-held device might be difficult to move over to other brands of devices. Desktop applications are hard to update with bug fixes or changes. Web programming is limited by the fact that most of the processing must be done by the server. (Going into more detail would require another blog post on its own.) Being aware of the limitations will help you ask for features that are appropriate for your medium, and will make the conversations you have with your developers about changing features much more productive.
Keep in mind that you are a team
Finally, keep in mind that most programmers, no matter what their background, experience, or skill level, want to write good software. Their focus may be different (most software developers I know will often over-emphasize quality code creation at the expense of the software as a whole), but in the end they want the same thing. They want the software to be successful as much as you do. From what I've seen, many of the problems between business and IT could be mitigated if everyone remembered that the end goal for everyone else is the same. Build trust, and good things should follow.
Basic Terminology:
User Interface - This is the term for the way in which the software user interacts with the application
Database - This is software that stores the data in most scenarios
Server - This is a computer, usually with a large amount of memory, that hosts the software or database
Hardware - This refers to the physical components of a computer
RAM - Think of this like short-term memory in humans: it stores information that might be needed in a few minutes, but does not hold information in the long-term
Refactoring - The process of rewriting working code to make it more readable
Data - Another name for "information", though "data" is plural
Development Process:
Writing software does not follow a predictable method or process. If it did, we could write software that could write software for us and save everyone a lot of time and money. (Most good programmers will do that when and where it is appropriate.) Because software writing is a highly creative and unpredictable process, nailing down solid estimates can be tough. If you try to force your developers to stick to their original time and cost estimates, you will likely create a contentious atmosphere which will get in everyone's way when trying to get work done. Instead be flexible to estimate changes. If it looks like a task or component is taking too long to complete, decide if it is worth completing after all. If so, keep in mind that the next estimate very well might be too large and you'll be even in the long run. If not, it is better to stop a time-consuming task early to avoid throwing good money after bad.
Early detection of problems is important
If you notice something strange in your application, especially if your data looks wrong or missing, find out what the cause is soon. Chances are that there's something wrong with your user interface and your data is fine, but if there's something in the application that's corrupting the data the sooner you can find the problem the easier it can be corrected. Lost data can be recovered from backups, but most companies only keep backups for a certain period of time.
Early detection is also important for problems like software slowness. If your software is slow, it is not likely going to speed up on its own, and will likely get worse over time. Fixing the problem early before complaints start coming in will save both you and your developer time and frustration.
Know what will change in your business requirements...and what won't
Many developers would disagree with me on this one, but I think it's important to communicate which of your business requirements will never change and which ones will certainly change over time. For example, if you have an e-commerce site that sells shirts, you might expect to add colors to your offerings, but you will not likely add sizes. The reason for this is that most developers will program non-changing requirements differently than ones that will change often. The non-changing requirements can be coded in such a way to make it easier and faster to write the first time, but harder to change going forward. The opposite is true for the changing requirements. This concept isn't critical, but it is something to keep in mind.
When problems arise, adding more bodies is probably not the solution
If a software project falls behind schedule, resist the urge to request additional resources to get it done. Why? Since, as I mentioned before, software writing is a relatively complex process, it will take time to get new resources up-to-speed on the specific requirements of your project. This not only means that these new resources will not be as effective as your current ones, but your current resources will be less effective than they were as they help bring the new resources into the project. Your best bet is probably to adjust your expected finish dates. If that is not possible, then adjusting the number of features to be added should be the next option.
It was working before....
Refactoring is an important part of the software development process. Adding features adds code, and unless you change existing code so everything makes sense to the developer you will eventually end up with a tangled, unmaintainable mess, to put it mildly. Therefore, most good developers will spend some time rewriting code to prevent this from happening. Every time this happens, the developer runs the risk of breaking something that was working before. There are ways of mitigating that risk, such as writing and running unit tests, but the risk cannot be completely eliminated. If you are testing changes made to your software, try to test areas that might be affected. Also, if you get complaints right after changes were applied about functionality that was working before, take them as seriously as any other.
Know the general limitations of your approach
I am not suggesting that you become a programming expert by any means, but you should be aware of the limitations of the software delivery method you choose. For instance, applications for a hand-held device might be difficult to move over to other brands of devices. Desktop applications are hard to update with bug fixes or changes. Web programming is limited by the fact that most of the processing must be done by the server. (Going into more detail would require another blog post on its own.) Being aware of the limitations will help you ask for features that are appropriate for your medium, and will make the conversations you have with your developers about changing features much more productive.
Keep in mind that you are a team
Finally, keep in mind that most programmers, no matter what their background, experience, or skill level, want to write good software. Their focus may be different (most software developers I know will often over-emphasize quality code creation at the expense of the software as a whole), but in the end they want the same thing. They want the software to be successful as much as you do. From what I've seen, many of the problems between business and IT could be mitigated if everyone remembered that the end goal for everyone else is the same. Build trust, and good things should follow.
Monday, September 6, 2010
Improving Business to IT Communication
A lot has been written about the disconnect between IT and the rest of the business. As an example of a common communication problem, here is an example of a conversation (a bit bland and contrived, I'll admit) which I have experienced all too often:
Business user: I have a customer with a problem with the application.
Programmer: What seems to be the problem?
Business user: When they push this button, I want them to see a message. Except they're not seeing one.
Programmer: Let me take a look to see what's going on.
- Pause -
Programmer: Their account is missing some information, which is causing the message to stay hidden.
Business user: That's not good.
Programmer: You can fix this problem by entering information on the "My Information" page.
Business user: Thanks, I'll ask them to do that.
Is there anything wrong here? Some people might argue that there is not, since the business user is able to do what he/she needs to, and this was just a training issue. I would argue, though, that there are two problems here:
…
Programmer: Their account is missing some information, which is causing the message to stay hidden.
Business user: That's not good.
Programmer: You can fix this problem by entering information on the "My Information" page, but I'd bet this will continue to be a problem with other users.
Business user: I agree. I can see how that message would be dependent on the "My Information" settings. Can we make filling out that information required?
Programmer: We could do that. We could also add default responses and ask the users to change the information if necessary.
Business user: Let's do that. I don't want to force them to fill out more information than is needed.
The difference here is that both the programmer and business user see that the underlying cause of the problem - missing information on the customer's account - should be fixed for more than just this one customer. Doing so would cause fewer headaches for both business user and programmer. They came to an understanding, and found a solution that worked for both.
While this situation was vague, the problem it illustrates is not. Technology personnel need to be sensitive to the business drivers behind their requests in order to suggest more complete solutions. Next week I will get into some more specific recommendations for business managers to get more out of their software development initiatives.
Business user: I have a customer with a problem with the application.
Programmer: What seems to be the problem?
Business user: When they push this button, I want them to see a message. Except they're not seeing one.
Programmer: Let me take a look to see what's going on.
- Pause -
Programmer: Their account is missing some information, which is causing the message to stay hidden.
Business user: That's not good.
Programmer: You can fix this problem by entering information on the "My Information" page.
Business user: Thanks, I'll ask them to do that.
Is there anything wrong here? Some people might argue that there is not, since the business user is able to do what he/she needs to, and this was just a training issue. I would argue, though, that there are two problems here:
- The application is not intuitive enough
- The underlying business problem is not fixed
…
Programmer: Their account is missing some information, which is causing the message to stay hidden.
Business user: That's not good.
Programmer: You can fix this problem by entering information on the "My Information" page, but I'd bet this will continue to be a problem with other users.
Business user: I agree. I can see how that message would be dependent on the "My Information" settings. Can we make filling out that information required?
Programmer: We could do that. We could also add default responses and ask the users to change the information if necessary.
Business user: Let's do that. I don't want to force them to fill out more information than is needed.
The difference here is that both the programmer and business user see that the underlying cause of the problem - missing information on the customer's account - should be fixed for more than just this one customer. Doing so would cause fewer headaches for both business user and programmer. They came to an understanding, and found a solution that worked for both.
While this situation was vague, the problem it illustrates is not. Technology personnel need to be sensitive to the business drivers behind their requests in order to suggest more complete solutions. Next week I will get into some more specific recommendations for business managers to get more out of their software development initiatives.
Subscribe to:
Posts (Atom)