Go offline with the Player FM app!
MBA228: Software Development Pearls
Fetch error
Hmmm there seems to be a problem fetching this series right now. Last successful fetch was on August 24, 2022 17:18 ()
What now? This series will be checked again in the next day. If you believe it should be working, please verify the publisher's feed link below is valid and includes actual episode links. You can contact support to request the feed be immediately fetched.
Manage episode 308313447 series 69451
Karl Wiegers shares his lessons on requirements, project management, design, quality and more. Karl’s advice can make you significantly better at what you do.
Show Notes
Karl Wiegers started programming in 1970 and has collected 60 lessons he has learned in several areas of software development including requirements, design, project management, culture, teamwork, quality, and process improvement. Each of these lessons bring insights that can help you to and your organization to become significantly better at creating high quality, valuable solutions to your customers.
The Need to Iterate
Almost everything we do takes more than a single shot and design is a good example. The first lesson in the design category of Karl’s book is “design demands iteration”. There’s always more than one design solution for a software problem and seldom a single best solution.
The first design approach you come up with is unlikely to be the best option. A good rule of thumb is that you’re not done with design until you’ve created at least three designs, discard them, and take the best ideas from those three and build something better.
The same holds true for requirements. It will take a few iterations to get it right. These are cyclical things that you have to plan in your project management approach. You’re going to have to build in some reviews, get some feedback, prototype, and do some modeling to make sure we’re on the right track.
Icebergs are always larger than they first appear; that means that there’s going to be growth in the project. There’s going to be new information and new ideas that come along. You have to build in that growth and include contingency buffers into your plans. The bigger the project, the more unknowns and ambiguity and the more likely it is to change.
Understanding Stakeholders and Customers
Usage-centric development (as opposed to user-centric) is more likely to satisfy customer needs than product or feature-centered development. We shouldn’t care about features as much as you care about knowing what people need to do with the product. That’s the difference between the usage-centric approach and the product-centric approach.
That begins by understanding your stakeholders. Stakeholders are individuals, groups, or even systems who can shape or influence the direction of a project or who are affected by the project. To be successful, you need to identify your various user classes and identify who’s going to be the literal voice of the customer. Keep in mind that the customer isn’t always right, but they always have a point. Many times, the customer may ask for a solution, which may or may not be the right thing. To provide valuable solutions, we need to understand the underlying problem. If the solution they propose is the answer, what is the question?
Listen to the full episode for more lessons and advice on stakeholders, quality, applying what you’ve learned, and more.
YOUR HOMEWORK Pick two areas you want to get better at and vow to spend some of your time on the project learning about those areas. Look for opportunities to apply that new learning on your project and perform in those areas better than you would have before your commitment to learn and develop your skill in that focus area. |
Links Mentioned in this Episode
- Karl’s Personal Website – KarlWiegers.com
- ProcessImpact.com – Karl’s business and book information
- Information on Karl’s book, Software Development Pearls

Karl Wiegers
Karl Wiegers is an independent consultant, author, speaker, and thought leader in the project community. His books on software requirements are considered required reading for Business Analysts and Project Managers. As a consultant and trainer, Karl has worked with more than 100 companies and government organizations of all types, helping them improve the effectiveness and efficiency of their software development activities.
Thank you for listening to the program
To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes.
Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.
Popular Episodes
The post MBA228: Software Development Pearls appeared first on Mastering Business Analysis.
276 episodes
Fetch error
Hmmm there seems to be a problem fetching this series right now. Last successful fetch was on August 24, 2022 17:18 ()
What now? This series will be checked again in the next day. If you believe it should be working, please verify the publisher's feed link below is valid and includes actual episode links. You can contact support to request the feed be immediately fetched.
Manage episode 308313447 series 69451
Karl Wiegers shares his lessons on requirements, project management, design, quality and more. Karl’s advice can make you significantly better at what you do.
Show Notes
Karl Wiegers started programming in 1970 and has collected 60 lessons he has learned in several areas of software development including requirements, design, project management, culture, teamwork, quality, and process improvement. Each of these lessons bring insights that can help you to and your organization to become significantly better at creating high quality, valuable solutions to your customers.
The Need to Iterate
Almost everything we do takes more than a single shot and design is a good example. The first lesson in the design category of Karl’s book is “design demands iteration”. There’s always more than one design solution for a software problem and seldom a single best solution.
The first design approach you come up with is unlikely to be the best option. A good rule of thumb is that you’re not done with design until you’ve created at least three designs, discard them, and take the best ideas from those three and build something better.
The same holds true for requirements. It will take a few iterations to get it right. These are cyclical things that you have to plan in your project management approach. You’re going to have to build in some reviews, get some feedback, prototype, and do some modeling to make sure we’re on the right track.
Icebergs are always larger than they first appear; that means that there’s going to be growth in the project. There’s going to be new information and new ideas that come along. You have to build in that growth and include contingency buffers into your plans. The bigger the project, the more unknowns and ambiguity and the more likely it is to change.
Understanding Stakeholders and Customers
Usage-centric development (as opposed to user-centric) is more likely to satisfy customer needs than product or feature-centered development. We shouldn’t care about features as much as you care about knowing what people need to do with the product. That’s the difference between the usage-centric approach and the product-centric approach.
That begins by understanding your stakeholders. Stakeholders are individuals, groups, or even systems who can shape or influence the direction of a project or who are affected by the project. To be successful, you need to identify your various user classes and identify who’s going to be the literal voice of the customer. Keep in mind that the customer isn’t always right, but they always have a point. Many times, the customer may ask for a solution, which may or may not be the right thing. To provide valuable solutions, we need to understand the underlying problem. If the solution they propose is the answer, what is the question?
Listen to the full episode for more lessons and advice on stakeholders, quality, applying what you’ve learned, and more.
YOUR HOMEWORK Pick two areas you want to get better at and vow to spend some of your time on the project learning about those areas. Look for opportunities to apply that new learning on your project and perform in those areas better than you would have before your commitment to learn and develop your skill in that focus area. |
Links Mentioned in this Episode
- Karl’s Personal Website – KarlWiegers.com
- ProcessImpact.com – Karl’s business and book information
- Information on Karl’s book, Software Development Pearls

Karl Wiegers
Karl Wiegers is an independent consultant, author, speaker, and thought leader in the project community. His books on software requirements are considered required reading for Business Analysts and Project Managers. As a consultant and trainer, Karl has worked with more than 100 companies and government organizations of all types, helping them improve the effectiveness and efficiency of their software development activities.
Thank you for listening to the program
To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes.
Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.
Popular Episodes
The post MBA228: Software Development Pearls appeared first on Mastering Business Analysis.
276 episodes
All episodes
×Welcome to Player FM!
Player FM is scanning the web for high-quality podcasts for you to enjoy right now. It's the best podcast app and works on Android, iPhone, and the web. Signup to sync subscriptions across devices.