Summary: We curate & disseminate outstanding stories from diverse domains to create synergy. Apply: https://digitalmehmet.com/contact & [https://illumination-curated.com...
ILLUMINATION
We curate & disseminate outstanding stories from diverse domains to create synergy. Apply: https://digitalmehmet.com/contact & https://illumination-curated.com
…why do we keep making the same mistakes over and over?
We’ve got the whole opposable thumb thing… and the gift of language… but what the heck? Why can’t we learn from history and start making some new mistakes and generating some new problems?
I’ve been working in the software development industry for over forty years… and haven’t seen a new problem since my first time around. I’ll outline them below… in hopes of reaching my younger self. It would be good to not retrace these in the future… but that’s up to you… and your leadership.
Later in my career, when called in to work on a tough program challenge, I used to say that I hadn’t seen a new problem in thirty years. Most folks thought that was funny and that I was just kidding them. Wrong!
Major Recurring Problems
The following problems been found to play a significant role in almost every software failure I’ve seen over my long career as a developer. They can be divided into three major (and measurable) categories.
- Effectiveness — degree to which the thing you’re making aligns with the thing you need.
- Efficiency — ratio of useful work performed (by a person or a machine) compared to the total energy expended.
- Robustness — condition of strength and good health; and capability to withstand or overcome adverse conditions.
In practice, time and time again, we find that most problems come from shortcomings in one of these areas. Below we’ll examine each area and expand each to see the specific gap between the level of quality needed versus the level of quality that is fielded.
These gaps are introduced by some shortcoming in our approach to business, architecture, process, or operations … and ultimately lead to failures in our software systems. But more on that after we discuss the standard problem set.
)
Mismatch Between Level of Needed and Level of Fielded Quality, ©2024 James R Carnes
1. Effectiveness Failures
1.1 Capability
- Suitability — capability fails to align with customer need and purpose; capability produces incorrect results.
- Usability — application, website, device, or process not easy to learn and difficult to use.
- Accessibility — product, device, service, or environment is not easily reachable by all users, as needed.
1.2 Performance
- Load — system fails to handle amount of transactional pressure applied to the system for start-up, steady-state and peak conditions.
- Throughput — system fails to handle amount of transactional flow through the system per unit time.
- Response — system fails to meet response time needed by the users for any collection of transactions.
1.3 Interoperability
- Openness — system fails to support syntactic, semantic, and cross-domain interoperability for information exchange.
- Backward Compatibility — system design fails to interface or operate with older applications, standards, or formats.
- Cross-Platform — system design fails to support operation of same high-level source code on differently configured hardware.
2. Efficiency Failures
2.1 Development
- Time-to-market — development fails to meet deployment timeline … from market definition to production operation.
- Velocity — development teams fail to meet release schedules … development teams are oversubscribed… i.e., to more work allocated than teams can successfully complete per unit time.
- Rework — release contains too many defects … and defect resolution times are too long. Insufficient time allocated to development with first-time quality. In reality the cost of rework exceeds the cost of doing it right the first time.
2.2 Sustainment
- Supportability — system design characteristics fails to permit upgrades during planned lifecycle.
- Maintainability — system cannot be easily kept current with new patches, versions, and releases.
- Testability — software artifacts are not designed to easily support automated testing.
2.3 Evolution
- Extensibility — software design fails to permit easy addition of new capabilities or features.
- Reusability — software design fails to permit easy modification for a new configuration of existing functionality.
- Scalability — software design fails to permit easy growth of application, network, or process as customer needs increase.
3. Robustness Failures
3.1 Availability
- Reliability — system or component fails to function under stated conditions for a specified period.
- Fault tolerance — system fails to continue operating properly in the event of a failure in one or more of its components.
- Safety — system fails to support life-critical (or mission-critical) operations as needed, even when components fail.
3.2 Recoverability
- Fault Resilience — system fails to provide and maintain an acceptable level of service in the face of failures or challenges to normal operation.
- Repairability — system fails to recover within acceptable timeframe and return normal function.
- Survivability — system fails to recover or continue capability after a natural or man-made disaster.
3.3 Cyber Security
- Network Security — system fails to monitor and prevent unauthorized access, intrusion, misuse, modification, or denial of a computer network and network-resources.
- Information Security — system fails to protect information by detecting and mitigating threat risks.
- Application Security — system fails to mitigate security vulnerabilities… at different stages of the software lifecycle.
Major Recurring Lessons Learned
The problems above provide an extensive set of mistakes that software companies make (over and over again)… that drive failure during development and in production. The good news is that you only need to incorporate a few disciplines into your approach to business, architecture, process, and operations to ensure you don’t repeat any of them. Good luck.
1. Business
Lesson: Focus on Customer operations. What problems do they need to solve. Don’t offer point solutions, build your business around products that improve end-to-end customer value.
- Focus on what Customers need. Understand customer needs and priorities for capability delivery. Customer priorities helps guide incremental deliveries by indicating what’s right and what’s right now.
- Focus on a Comprehensive Description. Even if you don’t have detailed requirements from the customer, get an agreement on the essential/important functional capability and expected performance.
- Focus on Customer Experience. It’s the front-end to your product… focus on what users need and how your product provides that function… simple to navigate and easy to use.
2. Architecture
Lesson: Include the customer in architecture and design decisions. Having their insight into the intended use of your product helps focus development on meaningful capabilities and supporting enablers.
- Make Functionality Extendable and Systems Expandable. Keep your design as simple as possible. Don’t include unnecessary complexity. The greater the complexity the harder it is to maintain and improve as needs inevitably change.
- Make Non-Functional Enablers integral to the Reference Architecture. A solid foundation makes everything else easier. Non-functional requirements are an important part of achieving first-time quality, but allocating budgets for them seems to be one the hardest software tasks for any company.
- Make Software Composable and Interfaces Interoperable. Accepting valid inputs (data, control, parameters) from other systems and sending correct outputs is fundamental to software systems. Work data models and interfaces first… then get the business logic and algorithms right.
3. Process
Lesson: Include the customer in the development process. It takes extra effort but can drive productivity. And it also helps manage user expectations and build customer confidence.
- Develop Capability the Customer Needs. Studies have shown that up to 65% of features defined during the development elaboration process… are never or rarely used by the customer. If you include the customer in this process, imagine the time and effort you could save.
- Develop Capability with Quality… the first time. If you don’t have time to build it twice, better get it right the first time. Yes, this may take a little longer for each feature, but the overall time saved on a larger project can be significant.
- Develop DevOps emphasis on Horizontal Integration. Don’t dwell on individual tools in the DevOps suite… focus on the end-to-end integration of all the tools in the process. Horizonal integration of the tool chain is the most significant factor in development velocity.
4. Operational
Lesson: The customer is counting on your products and services. Take the necessary steps to maintain, grow, and protect their operational investment.
- Integrate Fault Tolerance. Let’s face it… at some point in time, your software is going to fail. The good news is you get to decide whether this is a big deal, or just a small hiccup. Look for the most likely causes of operational failures and build-in the capability for graceful failover.
- Integrate Scalable Performance. Response time is critical… resource oversubscription is inevitable. Know the limits of your production environment… break them down into lower-level performance budgets with design provisions for elastic processing during peak use.
- Integrate Layered Security Provisions. Deploy an approach that leverages multiple security measures to protect every aspect of your operation. With a layered design, if one line of defense is compromised, additional layers still ensure that threats are handled.
Your Leadership Challenge
The common behavioral pattern present in each of the “ same-old problems ” above is the company (either intentionally or unintentionally) takes a quality short cut… for some reason that probably sounded good at the time. And it usually takes a ‘crisis’ for them to do the right thing.
So, what does it take to break this cycle… (and start generating a new set of problems)?
We appear to be good at observing the lessons from these software development issues. It’s up to you to actually * learn* the context and broader disciplines from these * lessons* and incorporate them into your software development culture.
Thanks for reading!
...
If you like what you’re reading and want to see more, please add * claps * and * follow* me on Medium.
Also, check out my book, “ Model, Build, Measure, LEAD!” … each chapter is published as a story on my homepage.
Model, Build, Learn, LEAD! (Book Chapter Links)
Lessons from a Lifetime of Developing Leadership Disciplines.
medium.com