Quality Software Development Principles
So, you have figured out how to build your applications, and they work just like the ones from which you learned. You are getting paid to write these applications, so you are now a professional developer. But how do you know if you are doing a good job?
There are literally thousands upon thousands of articles debating the measures of quality software with each of them offering you their own solution for how you should answer this question.
This body of work can be boiled down to a few questions:
Does the software do what it is supposed to do?
Of course, this is a loaded question. It is entirely possible to say that a piece of software does what it is supposed to do (as defined by a requirements specification), but this is absolutely worthless. In essence, you are talking about a failure of your requirements gathering process, which leads you to build the wrong thing. Your software is being built to serve a particular need, and if it does not satisfy that need (for whatever reason), the software is a failure.
Does the software do things it shouldn’t do?
Developers like to refer to this phenomenon as undocumented features, but your users will refer to them as bugs. Everyone prefers to build bug-free software, but in the real world, this just doesn't happen. All men may be created equal, but all bugs are not. Bugs that do not impact the functioning of the system -or the business process they support -are obviously far less important than those that do.
Did you deliver the software in a timely manner?
Timing is everything, and this is true nowhere more than in software in which the pace of change is incredible. If your software takes so long to deliver that it is no longer appropriate to the business process it supports, then it is worthless. The great untold secret behind the high percentage of software projects that end in failure is that many of them simply could not keep up with the pace of technological innovation and died trying.
Could you do it again if you had to?
Of course, you will have to! This is the job---writing and delivering software that complies with the preceding questions. The key here is that you should not have to learn all of your hard knocks lessons every time you build software. You will invariably be asked to deliver your software again with fixes and enhancements, and you hopefully do not have to fix the same bugs over and over again nor have the same integration challenges repeatedly. “At least we don’t have to deal with this next time” should be a truth that comforts you in your integration and bug fixing, and not a punch line to a development team joke.
These questions may seem like common sense---because they are! But there is an old saying that “common sense is neither,” so it is important not to assume that everyone is on the same sheet of music. Furthermore, the U.S. Army Rangers have a saying, “Never violate any principles, and do not get wrapped up in technique.”
You will find this a helpful maxim in dealing with the maze of processes, products, and techniques involved in software development. These are the core principles of software development, and how you get there is technique. Do not lose sight of the distinction between these two things.
So, you have figured out how to build your applications, and they work just like the ones from which you learned. You are getting paid to write these applications, so you are now a professional developer. But how do you know if you are doing a good job?
There are literally thousands upon thousands of articles debating the measures of quality software with each of them offering you their own solution for how you should answer this question.
This body of work can be boiled down to a few questions:
Does the software do what it is supposed to do?
Of course, this is a loaded question. It is entirely possible to say that a piece of software does what it is supposed to do (as defined by a requirements specification), but this is absolutely worthless. In essence, you are talking about a failure of your requirements gathering process, which leads you to build the wrong thing. Your software is being built to serve a particular need, and if it does not satisfy that need (for whatever reason), the software is a failure.
Does the software do things it shouldn’t do?
Developers like to refer to this phenomenon as undocumented features, but your users will refer to them as bugs. Everyone prefers to build bug-free software, but in the real world, this just doesn't happen. All men may be created equal, but all bugs are not. Bugs that do not impact the functioning of the system -or the business process they support -are obviously far less important than those that do.
Did you deliver the software in a timely manner?
Timing is everything, and this is true nowhere more than in software in which the pace of change is incredible. If your software takes so long to deliver that it is no longer appropriate to the business process it supports, then it is worthless. The great untold secret behind the high percentage of software projects that end in failure is that many of them simply could not keep up with the pace of technological innovation and died trying.
Could you do it again if you had to?
Of course, you will have to! This is the job---writing and delivering software that complies with the preceding questions. The key here is that you should not have to learn all of your hard knocks lessons every time you build software. You will invariably be asked to deliver your software again with fixes and enhancements, and you hopefully do not have to fix the same bugs over and over again nor have the same integration challenges repeatedly. “At least we don’t have to deal with this next time” should be a truth that comforts you in your integration and bug fixing, and not a punch line to a development team joke.
These questions may seem like common sense---because they are! But there is an old saying that “common sense is neither,” so it is important not to assume that everyone is on the same sheet of music. Furthermore, the U.S. Army Rangers have a saying, “Never violate any principles, and do not get wrapped up in technique.”
You will find this a helpful maxim in dealing with the maze of processes, products, and techniques involved in software development. These are the core principles of software development, and how you get there is technique. Do not lose sight of the distinction between these two things.
No comments :
Post a Comment