Steve McConnell reported in 1996 that "early upstream defects generally cost 10 to 100 times as much to remove late downstream as they do to remove close to the point where they are created.”
So why is it that we spend far more time, effort, and dollars on defect removal than defect prevention? Because, sadly, preventing problems is not sexy.
Many programmers and people in general, love to be the hero. Finding and fixing that critical error provides a great adrenalin rush. But when you consider time-to-market or cost issues, this model just doesn’t make sense.
A few of my go-to defect preventative tactics include:
• Requirements reviews
• Design and Code reviews
• Coding standards
• Writing test cases and plans early
• Automated build and smoke tests
-Judi
When it comes to technological solutions, you want a firm that has a proven track record of excellence. As one of the first software and hardware consulting firms in the Northeastern United States, Advanced Decisions is a leader in the industry. Our strength is not only in the experience that we bring, but also in our approach to developing solutions.
Showing posts with label Software Process. Show all posts
Showing posts with label Software Process. Show all posts
Tuesday, June 12, 2012
Monday, June 4, 2012
Creating Software Requirements Processes
It's hard to perfect your software development process without a solid requirements process in place.
I just finished up this video about software requirements processes that covers
Enjoy!
I just finished up this video about software requirements processes that covers
- How requirements are done in different software processes
- Proper requirements formats
- Who should be involved in the requirements writing
Enjoy!
Tuesday, May 15, 2012
Process Fanatics are Necessary
Most development executives want to improve their product development processes and achieve
And though all of these can be achieved with improvements to software development processes, they rarely seem to get done.
One recurring reason for not achieving these is the absence, in many software organizations, of a dedicated SQA (Software Quality Assurance) employee or department. Too often, management loosely assigns the responsibility to an already-overworked employee, which guarantees that SQA will crash and burn.
It's too bad that SQA is given such mediocre attention, because it's often the key factor in achieving better products that release faster.
Do you agree? Is SQA often the secret to better products?
-Judi
- Faster time to market
- Higher quality products
- Products that resonate better with users
And though all of these can be achieved with improvements to software development processes, they rarely seem to get done.
One recurring reason for not achieving these is the absence, in many software organizations, of a dedicated SQA (Software Quality Assurance) employee or department. Too often, management loosely assigns the responsibility to an already-overworked employee, which guarantees that SQA will crash and burn.
It's too bad that SQA is given such mediocre attention, because it's often the key factor in achieving better products that release faster.
Do you agree? Is SQA often the secret to better products?
-Judi
Monday, May 7, 2012
Who's Testing Your Code?
I often talk with software executives about the structure of their software development teams.
Some of their common questions are
I believe strongly in the last question's answer. There needs to be someone else besides the developer to test the product.
Yes, developers need to test code to make sure it’s working, but the test team has a completely different mentality and skill set. They should be trying to see where the software breaks, because if they don’t find those spots, a user will.
Who tests your code? Are they doing a good job at it? Let me know.
-Judi
Some of their common questions are
- Should developers interact with users? (Yes)
- Can developers write their own requirements? (Sometimes)
- Can developers test their own code? (No!)
I believe strongly in the last question's answer. There needs to be someone else besides the developer to test the product.
Yes, developers need to test code to make sure it’s working, but the test team has a completely different mentality and skill set. They should be trying to see where the software breaks, because if they don’t find those spots, a user will.
Who tests your code? Are they doing a good job at it? Let me know.
-Judi
Tuesday, March 13, 2012
Testing Real Time Embedded Systems
Gary Felberbaum, the Principal of Advanced Decisions, talks about testing real time embedded systems.
How early should someone consider testing?
The earlier that someone gets involved in setting up the strategy and setting up the architecture to enable testing is really important. You should to start thinking about how you will test an embedded system as soon as you are conceiving a project or an embedded system.
What is needed to get started?
The same steps are needed when starting to test or develop an embedded system. The starting process refers back to the simplest thing which is requirements: sitting down, defining what it is that you want to build, and then thinking about how to test the system (adding special electronics, special software, etc.).
Why is embedded system testing different from other software application testing?
It is different because you are interacting with a lot more real-world, physical processes. You’re measuring things that you may not have control over, while in application testing you can set up a test database and test against the test database. In the real world, for applications you have to think about how you’re going to simulate processes that you can’t control and that may take designing certain types of computer model and simulations that you need to do to make embedding system testing actually work.
Friday, September 2, 2011
Want to develop a new product? Where do you start?
I’ve been working with a lot of companies lately that have never developed a new product from scratch. They all seem to have the same question – “Where do I start?”
The answer is always the same – with requirements, and by requirements I don’t mean a bullet list of features, although that’s a start. By requirements, I mean detailed requirements of what you want the product to do and how it should behave in every situation. Error conditions are one thing that’s typically forgotten. Requirements are also not necessarily functional, for example, the maximum (or target) manufacturing cost is a common, and commonly overlooked, requirement for an embedded system. They say the “devil’s in the details.” In this case, that’s true.
The first question clients have (well, maybe it’s not the first, but it’s the big one everyone wants to know) is “how much will this cost?” Without the kind of detailed requirements I’m talking about, it’s impossible to give any kind of meaningful estimate. That’s why we’ve had such great success creating an initial engagement that delivers requirements and a rough estimate of time and cost. This initial engagement typically lasts between a week and a month, depending on the scope and complexity of the project and gives the client accurate information that they can use to make decisions. We usually find areas of trade-off, like features that could be in a future release, and can balance the client’s time to market and budget needs.
So remember, next time you have a new product you’re developing. Details, details, details!
The answer is always the same – with requirements, and by requirements I don’t mean a bullet list of features, although that’s a start. By requirements, I mean detailed requirements of what you want the product to do and how it should behave in every situation. Error conditions are one thing that’s typically forgotten. Requirements are also not necessarily functional, for example, the maximum (or target) manufacturing cost is a common, and commonly overlooked, requirement for an embedded system. They say the “devil’s in the details.” In this case, that’s true.
The first question clients have (well, maybe it’s not the first, but it’s the big one everyone wants to know) is “how much will this cost?” Without the kind of detailed requirements I’m talking about, it’s impossible to give any kind of meaningful estimate. That’s why we’ve had such great success creating an initial engagement that delivers requirements and a rough estimate of time and cost. This initial engagement typically lasts between a week and a month, depending on the scope and complexity of the project and gives the client accurate information that they can use to make decisions. We usually find areas of trade-off, like features that could be in a future release, and can balance the client’s time to market and budget needs.
So remember, next time you have a new product you’re developing. Details, details, details!
Friday, August 5, 2011
The Art of Requirements Writing
The one area where I see companies could improve and make a HUGE impact on their development is in Requirements Writing. Most companies err on the side of too little or, unfortunately, way to often, none.
The biggest problem we see as a result of insufficient requirements is almost always scope creep, meaning that because there is no baseline, features just keep getting added to a release, and the result often is that the release never gets released. The other common problem we see from non-existent or insufficient requirements is that what gets implemented is often not what was intended, and if by chance the implementation is done correctly, it has taken a lot more work, time, and interaction than it would have otherwise.
The other side of the coin is perhaps more interesting. It’s rare, but sometimes we see companies that put too much in their requirements. I think this fear is why some companies don’t do anything at all – they don’t want to spend eons writing reams of paper and analyzing every detail. Rightly so, it’s a waste of time. The kinds of things we see in this area fall into two main categories of content and formatting.
As far as content, the biggest error is trying to turn a Requirements spec into a Design spec, meaning that instead of detailing what needs to be done, the requirement details how it should be done. Now there is a place for this, but it’s not in requirements. Specifying the how in requirements really limits the options and almost always results in a sub-optimal design. If the requirements are being written by a business analyst, as good as they are, they are not usually experienced architects or developers. Even if they are being written by a developer, the benefit to separating what from how allows the developer to look at all the requirements as a whole and in a separate thought step design the how in the best way taking everything into account, not just one requirement.
As far as format, the least useful way to write requirements (and ironically, probably the most difficult way) is in paragraph or prose form. There’s just too much content, and the important points are not easily identified and digested. Additionally, it takes an additional step for every user of the requirements (development, QA, Tech writing) to get the relevant information out. Obviously Use Cases are a tried and true and very effective method, but even bullet points (as long as they contain enough information) are preferable. The information contained should include the user entries, the results, any exception or error conditions and any other affects of the feature, easily and quickly captured in a bullet point format without any extra text to wade through.
Bottom line – well written requirements are HUGELY helpful to everyone in the development process and will make a great impact on getting your product out quickly. I’m sure there are offenses I’ve missed here. What other kinds of things have people seen??
The biggest problem we see as a result of insufficient requirements is almost always scope creep, meaning that because there is no baseline, features just keep getting added to a release, and the result often is that the release never gets released. The other common problem we see from non-existent or insufficient requirements is that what gets implemented is often not what was intended, and if by chance the implementation is done correctly, it has taken a lot more work, time, and interaction than it would have otherwise.
The other side of the coin is perhaps more interesting. It’s rare, but sometimes we see companies that put too much in their requirements. I think this fear is why some companies don’t do anything at all – they don’t want to spend eons writing reams of paper and analyzing every detail. Rightly so, it’s a waste of time. The kinds of things we see in this area fall into two main categories of content and formatting.
As far as content, the biggest error is trying to turn a Requirements spec into a Design spec, meaning that instead of detailing what needs to be done, the requirement details how it should be done. Now there is a place for this, but it’s not in requirements. Specifying the how in requirements really limits the options and almost always results in a sub-optimal design. If the requirements are being written by a business analyst, as good as they are, they are not usually experienced architects or developers. Even if they are being written by a developer, the benefit to separating what from how allows the developer to look at all the requirements as a whole and in a separate thought step design the how in the best way taking everything into account, not just one requirement.
As far as format, the least useful way to write requirements (and ironically, probably the most difficult way) is in paragraph or prose form. There’s just too much content, and the important points are not easily identified and digested. Additionally, it takes an additional step for every user of the requirements (development, QA, Tech writing) to get the relevant information out. Obviously Use Cases are a tried and true and very effective method, but even bullet points (as long as they contain enough information) are preferable. The information contained should include the user entries, the results, any exception or error conditions and any other affects of the feature, easily and quickly captured in a bullet point format without any extra text to wade through.
Bottom line – well written requirements are HUGELY helpful to everyone in the development process and will make a great impact on getting your product out quickly. I’m sure there are offenses I’ve missed here. What other kinds of things have people seen??
Friday, June 24, 2011
Making the same mistakes
I hear it over and over again from technology execs – I know we should spend the time writing specs or working on our process or on architecture or designing a good UI or testing or documenting or - fill in the blank.
Yet, time and time again, I see companies making the same mistakes. It kills me! I asked myself “why do they do it?” After all, it’s so easy to improve your delivery time and quality a little bit at a time. I know it’s hard to find a place to start, but for some companies I see, anything would help them. When in doubt, remember that good requirements make everything else easier!
Then I remembered something I’ve heard repeatedly “The pain of the change must be less than the pain of the status quo”. I get that change is tough, but some of these changes (i.e. good requirements definition) are not that painful. I think a more accurate assessment would be “The fear of the unknown must be less than the pain of the status quo”
Do any of you have less than optimal practices in your product development? We all do, in one way or another. Things can always be better. Why do you stay where you are?
Yet, time and time again, I see companies making the same mistakes. It kills me! I asked myself “why do they do it?” After all, it’s so easy to improve your delivery time and quality a little bit at a time. I know it’s hard to find a place to start, but for some companies I see, anything would help them. When in doubt, remember that good requirements make everything else easier!
Then I remembered something I’ve heard repeatedly “The pain of the change must be less than the pain of the status quo”. I get that change is tough, but some of these changes (i.e. good requirements definition) are not that painful. I think a more accurate assessment would be “The fear of the unknown must be less than the pain of the status quo”
Do any of you have less than optimal practices in your product development? We all do, in one way or another. Things can always be better. Why do you stay where you are?
Wednesday, February 2, 2011
Software Process Improvement Consulting
In 2005, I joined Advanced Decisions to establish a Software Process Improvement practice within the company. Well, long story short, I got busy with our core business of software and hardware product development and we never formally developed that practice. The interesting thing is that we seem to provide consulting on Software Process and SDLC as part of many of our engagements anyway.
The most obvious example is our work with start-ups. We typically are engaged to develop their product, but often wind up developing their process, their team, and even on occasion aspects of their business. With our larger clients we develop good quality documentation that’s often used as an example of what to develop in the future. Even with our prospects, we ask them enough questions about how they are developing their products to get them thinking.
It just goes to show, the outcome of a goal or desire may not always look like you expect.
The most obvious example is our work with start-ups. We typically are engaged to develop their product, but often wind up developing their process, their team, and even on occasion aspects of their business. With our larger clients we develop good quality documentation that’s often used as an example of what to develop in the future. Even with our prospects, we ask them enough questions about how they are developing their products to get them thinking.
It just goes to show, the outcome of a goal or desire may not always look like you expect.
Friday, October 23, 2009
Feast or Famine in Software Development Organizations?
In so many areas of my life I go thru these cycles of feast or famine – social engagements, work load, car problems, what have you. I either have lots or none, or is that just my perception?
There’s one area that I can think of in which I’ve never had this problem – the software development organizations I’ve been a part of. Sure, we’ve had that with bugs, or turnover, but never, ever, ever workload. There was ALWAYS more than enough work to do. Maybe it’s just the nature of the beast – companies always want to improve their products and there are a wealth of ideas on how to do that. It’s also a positive thing. I love being busy, and if a company can not keep it’s developers busy, why does it need them?
The downside however can be a feeling of overwhelm, or inefficiencies, or continual long, long weeks. What kinds of things can we do to smooth this out a bit, or at least mitigate the negatives? I have some ideas:
1) Prioritization – so many organizations are SO bad at this. The priority is the priority of the moment, based on the loudest customer, one data point, or the whim of an executive. A well thought out prioritization can allow your development teams to get more done, just by finishing what they’re already working on. I’m not saying it should never change, but it certainly should change less frequently than you change your clothes.
2) Focus – knowing the big picture will help with number 1, as well as with coherency of design and team morale. If you’re building something to do x, don’t try to do y. Pick one thing (at least to start) and do it exceptionally well
3) Learn to say “No” – I find that people (not just in development organizations) spend an inordinate amount of time exploring roads not taken, as in “maybe we should have done x”. I once heard a speaker call this “Killing the un-chosen alternative.” I like that, and not because I’m violent – I’m not. I like it because it allows you to devote 110% of your attention to being successful on the path chosen and stop second-guessing yourself, a time wasting distraction if there ever was one.
I for one hope there isn’t a famine of new product ideas or developers to carry them out. Let’s just try to do it sanely.
Sunday, September 28, 2008
Messiness
I happen to be one of those people who are very organized. In fact, I don’t function very well when I’m not. My desk is neat, my files are organized, and when they are not, I am not as productive. I don’t consider my self compulsive, but I suppose some might.
I think this kind of mindset has made it very easy for me to adopt and appreciate a formal development process and good architectural standards. I’ve known a lot of people who have offices or workspaces in which every available surface is covered with piles of stuff. Similarly, I’ve know developers whose code is just as “messy” - inconsistent coding standards (even with themselves), poorly partitioned, intertwined spaghetti.
Do you think some people are just naturally predisposed to be “neat” in all areas of their life? Can developers that are not naturally predisposed to this find comfort and value in good development practices?
I think this kind of mindset has made it very easy for me to adopt and appreciate a formal development process and good architectural standards. I’ve known a lot of people who have offices or workspaces in which every available surface is covered with piles of stuff. Similarly, I’ve know developers whose code is just as “messy” - inconsistent coding standards (even with themselves), poorly partitioned, intertwined spaghetti.
Do you think some people are just naturally predisposed to be “neat” in all areas of their life? Can developers that are not naturally predisposed to this find comfort and value in good development practices?
Thursday, April 3, 2008
Full Process Review or Quick Fix?
Lately we seem to have so many consultants interviewing for so many opportunities it's hard to keep track of all the details. We do have some tools in place but they're not enough. When the "pain" gets to be too much we've been creating quick fixes to relive the particular difficulty we're having at the moment.
In a casual hallway conversation, we were just about to do this again, when it dawned on me that we had not really looked at our end-to-end process and inter-relationships between Sales and Consultant Services in a while. Certainly not since our business volume has picked up. My Software Development background kicked in and I suggested we take a step back and do just that.
I know that when we're moving so fast, it can be tempting to just address the immediate issue, but sometime a more holistic approach is the way to go. The trick is in knowing the difference. I think, just like in Software Development too many quick fixed can create a mess really quickly. In this case, we had been doing the quick fix thing for a while and it just seemed like time to look at the big picture.
In a casual hallway conversation, we were just about to do this again, when it dawned on me that we had not really looked at our end-to-end process and inter-relationships between Sales and Consultant Services in a while. Certainly not since our business volume has picked up. My Software Development background kicked in and I suggested we take a step back and do just that.
I know that when we're moving so fast, it can be tempting to just address the immediate issue, but sometime a more holistic approach is the way to go. The trick is in knowing the difference. I think, just like in Software Development too many quick fixed can create a mess really quickly. In this case, we had been doing the quick fix thing for a while and it just seemed like time to look at the big picture.
Subscribe to:
Posts (Atom)