Reduce Decision Workload with Software Choices
•Download as PPTX, PDF•
0 likes•2 views
Software engineering involves significant decision making. When deciding whether to implement a feature using pre-built components or building it from scratch, considering how each option affects decision workload can guide the choice. Using pre-built components may reduce workload by avoiding design decisions, but integrating and configuring the components still requires decisions. Building internally means all design decisions are required upfront but future context and decisions are clearer. Evaluating documentation quality and reuse potential of either approach also impacts decision workload.
Recommended
Recommended
More Related Content
Similar to Reduce Decision Workload with Software Choices
Similar to Reduce Decision Workload with Software Choices (20)
Recently uploaded
Recently uploaded (20)
Reduce Decision Workload with Software Choices
- 1. Barry Hennessy. Oct 7, 2022 Does it reduce your decision workload? A question to guide to software engineering
- 2. Decision workload ~= Engineering workload Software engineering is decision making All models are wrong, some are useful.
- 3. An example is in order Should we implement X by with plug-n-play components or build it ourselves?
- 4. Plug-n-play components • You won't have to decide • How to build those individual components • You will have to decide • Which components to use • How to use those components • How to integrate them • How to secure them … etc How would this route affect your decision workload?
- 5. Context is costly How good is the documentation? • Terrible documentation? • It’s harder to gather context from poor documentation • That increases your decision workload. • The decisions you've to make will be harder. • Great documentation? Good, relevant, integration examples? • That's reduced decision workload • tickety-boo!
- 6. Build it yourself • You have to make all the decisions involved in putting it together. • But you know exactly how to do it • You’ve probably made something similar before • Maybe you’ve documented well and can re-gather context quickly • You can use all the tools you've already used before • How you use these tools best are decisions that have already been made How would this route affect your decision workload?
- 7. Choose your own adventure Ask: “does this reduce my decision workload?” It can quickly surface which path will work best for you.
- 8. @BHennessySoft Software engineering is decision making. I want to help you navigate your software decisions. Reach out to barry@barryhennessy.com linkedin.com/company/barryhennessy barryhennessy.com
Editor's Notes
- Guide through software engineering practices.
- Model of software engineering. All models are wrong. Decisions permeate software engineering - How should I tackle this ticket? - Software architecture - what tech for the next 10 years?
- Javascript ecosystem -> a lot of filtering to make the decisions. High decision workload Small components = more decisions
- Gathering context is part of any good decision. You’re looking at how the documentation affects your decision workload.
- If you haven’t made something similar before then beware. This had better be a learning exercise. You’ll build what you need. It’ll be leaner. Easier to maintain (future decision workload).
- The crux of it. You probably are facing your own software decisions if you’ve listened to me this far. Which path to take depends on you, your history and the task facing you. Reduce the decision workload for you and your team.