Chapter 9. - Maximizing Performance

Organization & Development —

Why do you need to know this?

What will you learn?

• The main ideas from two process improvement systems, Lean and Six Sigma specifically adapted for the technical aspects of software development.

• The relationship between our everyday tasks and the theoretical ideas we discussed so far.

• What makes for an effective development process.

• How to measure the performance of the work.

Gain control - Six Sigma

Common Concerns of Control (C3)

• Human factor: The skills, experience, motivation and persistence of the employees working on the given task is hugely influential in the achievable level of process consistency.

• Complexity: When the business domain is large, and the offered functionality is diverse, it's harder to handle all tasks with predictable quality.

• Collaboration: The number of third parties to collaborate with during the execution of the task. Because they are outside of the company's control, they lower the general level of influence over the consistency of processes.

• Communication: The amount of communication that needs to happen. The number and size of involved teams is a major factor in this, The quality of the in-use personal and team discussion apps, forums or wikis are also a factor in its effectiveness.

• Dependencies: The number and quality of the connected systems and used tools developed and/or maintained by external parties also make it harder to achieve control over the delivery process of the whole system.

• Tech: The reliability of the hardware, software and cloud infrastructure used for getting the work done is also a factor in the stability of the processes.

• Tracking: project and task management tools and their integration into the workflow, with the goal of tracking work progress. The better you track, the more insight you have, the higher level of control becomes achievable.

• Automation: The degree of automation implemented at the different stages of work.

Concerns of Control by SDLC Stages

Reduce waste - Lean

• Overproducing
More products are generated then demanded
This can happen as the result of miscommunicating the company goals, the failure to align the done work with those goals or simply setting up the wrong goals. In software development it manifests as:
1. Shipping unnecessary or misprioritized features that were not validated and are not valuable to the users
2. Fixes delivered, that are not prioritized according to the needs or feedback of the users
3. Any kind of development, maintenance or support for products and features that doesn't or hardly bring any benefit to the company.
4. Rework needed because of changing requirements or changing tools & technologies.
5. Implementing the same thing by different teams because of technology divergence or non-uniformity.
6. Maintaining and supporting a lot of older product versions especially when upgrading to the latest versions is an internal, organizational question of the company.
In the COOP terminology it's a COO, so a CO2 🙂 problem. The lack of a clear strategy (control), or the lack of overseeing it's execution can be the reason of working on the wrong things. The other possibility is poor organization of the tasks. This issue mainly impedes the effectiveness of the company, as we are solving the wrong problems, holding back the delivery of real value.
Tracking usage metrics, getting real customer feedback, reviewing financial performance and development efficiency enable quantifying these issues.
Summary: Unnecessary development work on the product
💡
Connection to tech choices This is the only waste where - despite my best effort - I couldn't find a link to any property of the tech tools.
 

• Waiting
Time spent unproductively waiting for the next step to begin.
The cause can be organizational, like inefficient communication between the dependent parties, unsynchronized parallel processes that are interdependent at times, redundancies in the production flow, the inefficient scheduling of tasks, lack of resources, overly complicated workflows or the wrong assignment of roles and responsibilities. The other sources of waiting can be the used technologies and the development process:
1. Long time passing between making a change in the code and seeing it's result. Examples are lengthy compilation, build or deployment times. When the applications themselves are slow or unnecessarily complex that contributes to this issue.
2. Monolithical codebases, where making a single change affects many unrelated parts of the system. This can cause huge delays in rolling out updates. Especially if the work of multiple teams have to be synced up for a single release.
3. Low degree of automation in the development, testing and deployment processes. Lacking things like codemods for automatic tech migrations.
4. Bottlenecks in development, like poor tooling, lack of capacity to amend pull requests or to help juniors.
5. Unstable software or hardware used for either development, testing, deploying or running the applications. It's a waiting type waste because the time spent troubleshooting their issues is unproductive.
6. Debugging issues is harder than necessary. Because the low quality or lack of tooling, nonexistent logging and monitoring, lacking documentation etc...
7. Immature solution with weak or non-existent ecosystem and community??
8. Difficult upgrade processes taking time away from delivering features, because of incompatibilities or breaking changes.
9. Inconsistencies between the implementation of the same application concerns across different projects causing company wide improvements hard to roll out and making it difficult taking over other teams' work.
10. Reinventing the wheel, or building a custom solution to a common problem when an open source alternative would deliver the same value or buying a product would still have a good ROI.
In COOP terms its a POO an OOP matter, primarily affecting the production part in terms of utilization and efficiency. Many of them are the result of problems in the overseeing and organizing areas. If we can foresee them, it's our responsibility to either mitigate or to raise attention to them. Where we have direct control, the production phase, the source are technical. The quality of our choices are the driving forces in creating or solving these bottlenecks. Most of these problem only belong to this waste category, when there are alternative solutions that offer the same benefits without the problems mentioned above.
Measuring this area is quite straightforward, tracking the time it takes to pass each phase of delivery and the total or lead time can show where the bottlenecks are. Keeping track of the time while the delivery can't proceed because of software or hardware issue is tricky, but doable an it can help to raise attention to the source of inefficiencies.
Summary: Unnecessary waiting during work
💡
Connection to tech choices - Will the usage of the tech fit into the existing workflow without blocking it? - If not, can you reorganize the processes to eliminate the waiting? - Will other teams become dependent on your work? If yes, how does that affect the overall process? - Will other systems become dependent on yours? If yes, how does that affect the overall process? - Is the tool stable? Will it increase the number of times the system becomes worse or unusable in any way? - Is it easy to find help in troubleshooting the issues of it's usage? That can mean documentation, online communities, the knowledge of coworkers or available developer tools. - Does it affect the testing of the product? If yes is it easy to automate it? - Will you be able to quickly get approval to use it? - Is there enough workforce capacity to effectively integrate it? - How's the learning curve? Does it take long at the initial phase to get productive? - If yes is it offset by other benefits? - Will it influence the speed of seeing the effects of code changes? - Does it's usage increase the coupling of the classes / modules / services / codebases?
 

• Transport
Unnecessary transportation of products or materials
The cause of this waste is usually a non optimal choice, similarly to the waiting case, when there are better alternatives that make the complexity of the used solutions wasteful in comparison. The correlations between the classic meaning and software development are a bit more far fetched here than with the other waste types but they are valid concerns. What I found to resemble transportation are:
1. Compilation: Some tools require their own transformation steps to integrate with the rest of the software in use. It can mean compilation, transpilation, minification, conversion, packaging, etc.. The opposite is true as well, many times there are tools that don't require these to solve the same problems, which means moving code through those steps are actually wasteful.
2. Data handling: When doing unnecessary movement of data we are generating a transport type waste. Such cases can include: a too heavy backup strategy, migrating between different technologies in vain, an overly complex data processing pipeline. These can be the results of working with legacy systems, or changing requirements, but the final result is a system that could be doing the same job using less resources.
3. Tech migration: When modernizing a solution, or adjusting it to a new situation we often enter a period of transitioning between the usage of the old and new technologies. Depending on their nature It might be a complex, blocking process, that in the end requires a total rewrite of the software, or instead, we can use incremental adoption, going in small steps and continuing feature delivery while working on the migration. So in a sense we avoid putting the old codebase through an unnecessarily complex transportation process.
4. Version control workflow: For smaller projects a complex branching strategy might simply mean the movement of code through a process without real benefits.
5. Deployment process: It should be aligned with the real needs of the project, sometimes the benefits of a complex automated pipeline simply won't pay off. When a simple solution suffices don't go for an overkill.
6. Knowledge transfer: When there's a role or responsibility change oftentimes it creates the need to pass on the knowledge of the person who is leaving the post or task to the next one. Somebody has to really mess up for this to go wrong, but if either the knowledge or the receiver is not what it's supposed to be, then the effort is really wasted. This most likely would only happen if the process starts earlier than the final decision are made about the change.
In the classic case, the existence of transport issues would show that, there are problems in the "organize" aspect. However for software development I found it is purely related to the "produce" phase, which means it's totally in our hands and by using the better alternatives we can eliminate them.
Measuring these factors are quite tricky. Similarly to waiting, the detailed tracking of the status flow and the completion time of the different task can reveal insights about the above issues. Monitoring the performance of the applications can show if there are problems with data handling.
Summary: Unnecessary steps in the development processes
💡
Connection to tech choices - Will it add new steps to or simplify the development workflow? - Will it add new steps to or simplify our data processing? - Will it add new steps to or simplify our deployment process? - Will it require migrating data from our current storage solutions? - If yes, how costly that is? - Does it require the rewrite of existing code? - If yes, how much of it? Can it be done incrementally?
 

• Overdelivering
More work is done or higher quality is produced then required
Just as with overproducing this can happen as the result of miscommunicating the company goals, or of the failure to align the done work with those goals. It translates to:
1. Premature optimization of any software property like: performance, availability, resource usage, security, UX or any other unjustified capability
2. Overengineered solutions
3. Code added just in case it might be useful in the future
4. Creating a framework to build the product when the problem's complexity or the available solutions doesn't justify it
Similarly to overproducing in COOP terms, it's an OO problem. At least the strategy is clear this time. The issues are with organizing the work or with overseeing it's execution. It can mainly impede effectiveness as we are solving the wrong problems, holding back the delivery of real value.
I don't know about any good measure to track some of these issues explicitly. The premature optimization concerns can be verified by user research that explores whether there's a real need for those properties or not. For the rest, the closest we can get to useful measurement is again the time and task progress tracking. It requires a lot of experience in delivering projects to realize just from those number that something is off in this regard. Nonetheless when investigating the reason for a slow development process these issues might show up.
Summary: Unnecessary improvement of the code
💡
Connection to tech choices - Are the main strengths of the tool really useful for the project? If not, then using it will result in overdelivering in those areas. You don't need the world's fastest solution for every problem. - Will it inevitably add or include functionality that we don't need? - Does the tool encourages creating simple solutions or will it lead to bloated code?
 

• Inventory
Unused products or material taking up storage space- and cost
It's classically a logistics problem but in case of development it's cause is poor planning and/or the lack of oversight from the side of development or business.
1. Already developed code that nobody uses, because there never was a real use case for them. It can be a consequence of overdelivering. It's a very minor waste, it only becomes relevant when a developer has to spend effort in vain to understand why does that code exists and if it's useful for anything just to find it's not. This gets worse if there are lots of cases, especially if the codebase has low findability or readability.
2. Unused capabilities of the hardware, software, framework, library or any tool, especially if we paid for acquiring them. It becomes a real waste when the job could be done more efficiently using them but they are not utilized.
3. Employment of developers whose skills and knowledge is no longer relevant to the company.
In terms of COOP, it's a P concern. The wasted developer capacity sets back the efficiency of work, and the unused capabilities impede utilization.
Many technology specific tools can help with identifying and removing unused code so they can be used to track that issue. I don't know about any good measure of unused capabilities. Tracking employee utilization can show who is doing useful work and who isn't.
Summary: Wrongly or non utilized resources
💡
Connection to tech choices There's no real factor to consider from this perspective. To prevent the generation of this waste, the mitigation should happen when evaluating the effects of the tool on waiting, transport and overdelivering.
 

• Motion
Unnecessary movement of people
This is the same for software development as for any other kind of intellectual work. All the issues here create expenses without a return.
1. The ineffective reorganization of teams or management.
2. Unnecessary training of employees.
3. Forming internal communities or starting initiatives that are not aligned with the company strategy.
4. Ineffective employee activities. Anything that is mainly about person to person interaction like: meetings, decision processes or supporting colleagues.
5. Switching people between tasks before completion.
It's mostly an O issue, where O stands for the "organize" aspect. A less likely source can be the creation of a wrong strategy by the leadership, or the failure to align with the real goals, from the side of management. So the full range of possibilities is CO2.
Measuring and tracking purely organizational efficiency is a topic I consider too far related to cover here.
Summary: Unnecessary spending on employees
💡
Connection to tech choices It's an area without a direct link to technology, but this waste can appear as a consequence of a misaligned tech decisions. When a non-ideal solution is adopted it might lead to the need of employee training, or the forming of communities around it, that further adds to the costs of the choice. In more complicated situations, the adoption of a technology by a given team might result in reorganizing the setup of the workforce. For example a member from another team with much more experience using the tech might be planned to move into the adopting team. In these cases it's good to consider the personal and team effects of such changes and explore if the adoption can happen at other teams with more human factor or organizational benefits.
 

• Defects
Creation of faulty or low quality products or services
This is the most familiar type of waste to developers but it's not always our fault if the results are defective or low quality. A solution can end up being wrong with a perfect implementation if the requirements or designs were poorly made. When the requirements change frequently, it's hard to create a decent solution. The lack of proper testing is not to blame for the existence of issues but contributes to the delivery of them. Even when the software is well tested and bug-free (never), if the deployment process creates outages or the environment where it runs is unstable it will still make a bad impression of the product as a whole. The time it takes to release a new version can also influence the users' impression of the quality. That speed can be impeded by bad organizational structures and processes, which are sometimes the sole responsibility of management. If the company doesn't listen to feedback from its customers, that will also damage the perception of the product. Lastly unrealistic budget and scheduling can also lead to low quality software even when the best development tools and practices are used. It's our responsibility to call attention to these issues when they are not under our control because many times the decision makers aren't aware of the consequences. I hope for the best outcomes to you in such cases. In my experience these are often the hardest problems to remedy. With all that out of the way, let's see how we influence this area.
1. Tech: Not all programming languages, frameworks and libraries are equal in the quality of software we can produce with them or in the effort that's needed to produce the same quality. The likelihood of making mistakes has to be analyzed for each tool and evaluated against all choices. A very good indicator of how good a tool is in this regards is maturity: It means it's well know how to make best use the tech and how to avoid its pitfalls. The quality and amount of available documentation, training and online help should be high. Just as the quality of its codebase and activity level in its community. Of course there are many specific factors depending on what kind of technology we are talking about. Always try to investigate what are the relevant aspects of the tools can increase the number of programmer errors.
2. Best practices: Most technologies have well established best practices to prevent creating bugs. Knowing and applying these are a major factor in the number of defects we generate.
3. Standards: If the project adheres to a common standard, that can prevent issues caused by inconsistent naming or folder structures, bad readability, findability or hard to follow version history. It also means if the project uses tools to enforce the standards, and their effectiveness in it.
4. Quality control: The existence or lack of pair programming, code reviews, mentoring, TDD practices.
5. Code complexity: There's only so much a programmer can keep in mind when working with code. The more parts and more connections between them are in the system, the harder it is to keep track of everything and thus the probability of making mistakes increases with their number. Any practice or tool that helps keeping complexity low is beneficial.
6. Human factor: The programming and business domain experience of the developers are very impactful on the bug count. Egoistic persons are also more likely to overestimate their capabilities and then make mistakes or compromise quality.
7. Maintainability: There are many components of maintainability. Some are specific to the tools in question, but others are generic like the open-closed and single responsibility principles, low coupling, low tech debt, good amount of documentation and comments. The points discussed at the Standards section are also relevant here. When a codebase is maintainable it helps to onboard new colleagues or to hand over the work to another team with minimal extra risk of them creating new issues. In the case of third party code, it helps speeding up adaption and increases efficiency while working with it.
Our part is strictly the P from COOP, but the other aspects outside of our direct influence are also relevant so all in all it's an OOP matter, affecting mostly efficiency and to a smaller degree effectiveness through the quality control measures.
To quantify the best practices and standards issues we can use technology specific tools. For most mainstream languages and frameworks at least exists to track those statistics. To track code review and TDD practices we can use CI/CD tools. Tracking code statistics like the size and number of modules and services, code complexity, changes in LoC can indicate the total complexity of a system. Many other aspects are best judged by humans at this time, like the experience of developers or the maintainability of code.
Summary: Neglect of developer wisdom and best practices
💡
Connection to tech choices The part about our influence is actually describing the connections, make sure to evaluate the tools against all of them. - What are the factors at play that influence the likelihood of programmer error? - Are there well known best practices to follow? - If yes, are they easy to integrate into our workflow? Can we automate it? - Are there well known standards to use? - If yes, are they easy to integrate into our workflow? Can we automate it? - Will it influence the effectiveness of the quality control we do? - If yes, does it require extra cautions, or can it remove some checks we do? - Will it increase, simplify or won't have any effect on the complexity of the code? - How well experienced are the developer with the tool? - How will it affect the maintainability of our codebase? - How maintainable is the tool's own code?
 

• Underutilization
Not taking full advantage of the available skills and knowledge of the employees.
This is quite straightforward but not really software centric. The general part is to ensure the growth of talent at the workplace, and to assign people to matching positions. Mentoring and training are keys for the first to happen, the second is an HR matter, but as experts we should be able to assess people's knowledge and their match to a certain task. The only technically related matter I identified is the following.
1. Unification: When the same tool (language/framework/runtime/whatever) can be used for doing tasks that was or is done by multiple different technologies or people. It is an opportunity to increase the utilization of the available resources. Two common examples of this are: full stack developers and isomorphic JavaScript. Another frontend related tech is WebAssembly which offers similar advantages.
From COOP it's OP again, and for the first time it's really strongly connected to the division of labor aspect (P), as a more efficient and well utilizing setup can be achieved through unification in some cases. The general concerns reflect how well organized the work is.
Measuring this again means tracking organizational effectiveness, which I'm not covering.
Summary: Unused employee potential
💡
Connection to tech choices - Can the tool unify previously separate roles and responsibilities? - Does it require to divide existing roles and responsibilities? - How these changes affect the other process properties?
 

Development process quality analysis & improvement

1. Identify all distinct steps in the creation and delivery of software.

2. Identify the control concerns and sources of variation at each step.

3. Identify the types of generated waste and what creates them.

4. Set up the baseline measurements about the process performance per control concern.

5. Set up the baseline measurements about the amount of generated waste.

6. Analyze how big is the effect of each issue on all 3 kinds of value.

7. Prioritize them by their impact on the most important values.

8. Eliminate as much randomness and waste as possible, and measure the impact.

9. Refine and repeat.

Takeaways

TL;DR