14. Concluding Thoughts
The previous chapters focused on the technical aspects of designing a project. Certainly, you can view project design as a technical design task. After practicing project design for decades, I find that it is actually a mindset, not just an expertise. You should not simply calculate the risk or the cost and try to meet your commitments. You must strive for a complete superiority over every aspect of the project. You should prepare mitigations for everything the project can throw at you—which requires going beyond the mechanics and the numbers. You should adopt a holistic approach that involves your personality and attitude, how you interact with management and the developers, and the recognition of the effect that design has on the development process and the product life cycle. The ideas I have laid out for system and project design in both parts of this book open a portal to a parallel level of excellence in software engineering. It is up to you to keep that portal open, to keep improving, to refine these ideas, to develop your own style, and to adapt. This concluding chapter advises how you should approach these aspects, but more importantly shows you how to continue the journey.
When to Design a Project
There are several answers to the question of when to design a project. One straightforward response is “always.” Compared with the dismal state of affairs for most software projects, what project design has to offer is understandably quite compelling.
As an engineer, I am wary of absolute answers like “never” and “always.” You should answer the question of when to design a project from ROI perspective. Compare the time and cost of designing a project with the benefits of building the system in the fastest way, the least costly way, and the safest possible way. Since it takes just a few days to a week to design a project, from an ROI perspective it is easy to justify designing most projects. Furthermore, the larger the scope of the project, the more you should invest in project design that gives you the optimal solution. With a large and expensive project, even a minute change from the optimal point could be both huge in absolute terms and likely to surpass the cost of designing the project.
Another answer to the question of when to design a project is “whenever you have an aggressive deadline.” Even without compression, merely having the most efficient team assigned along the critical path of a plain normal solution will beat any other approach, especially compared with projects that attempt to build the system iteratively.
The Real Answer
The final answer to the question of when to design a project is the most important section in this entire book. Imagine you have an idea for the next killer app, something that could be immensely successful. You need some capital to build it, to cover costs from hiring the people to paying for cloud compute time. You could seek venture capital in exchange for most of the equity and then work 60 hours a week for several years on something that is likely to fail. You could also self-fund the project: You could sell your house, liquidate your pension plan and life savings, and borrow from friends and family.
If you choose the self-funding route, would you invest in project design? Would this investment be a little investment in time and effort or a large one? Would you say that you do not have time for project design? Would you say that it is better to just start building something and figure things out later, or will you do whatever it takes to find out if the project is affordable before becoming broke and destitute? Would you skip any of the techniques or analysis of project design? Even if you can afford the project, would you not still design the project to identify the risk exclusion zones? Would you repeat all the calculations a second time for good measure? Would you first design the project to see if you should sell your house and quit your job? After all, if the project requires $3 million and you were able to muster only $2 million, you should keep the house, not the new startup. The same goes for the duration of the project. If you have only a one-year marketing window and the project is really a two-year project, then you should do nothing. When self-funded, would you also not prefer that your developers work against detailed assembly instructions of the project, as opposed to wasting your scant resources trying to figure it out on their own?
Next, imagine a project where the manager is held personally liable for any failure to meet the commitments. Instead of the manager earning a nice bonus when meeting the commitments, in the case of failure the manager has to pay out of pocket for the project cost overruns, if not the lost sales, as well as any contractual obligations. In such a situation, would the manager oppose project design or insist on it? Would the manager resist project design because “that is not how we do things here”? Would the manager invest a little or a lot in system and project design to ensure the commitments are aligned with what the team can produce? Would the manager avoid finding out where the death zone is? Would the manager give up on sound architecture that will ensure the project design itself will not change much? Would the manager say that since no one is working this way, that is a good enough reason not to design the project?
The dissonance is stark. Most people have a callous, cavalier, and complacent attitude when the company is paying. Most people avoid thinking for themselves because it is so much easier to dogmatically follow the common practices of a failing industry and use that as an excuse when squandering other people’s money. Most just make excuses such as that they do not have the time, or that project design is the wrong process, or that project design is over-engineered. Yet when their head is on the chopping block, the same people become project design zealots. Such a difference in behavior is a direct result of lack of integrity, both personal and professional. The real answer to the question of when to design a project is when you have integrity.
Getting Ahead in Life
The best career advice I can give you is this:
Treat the company’s money as your own.
Nothing else really matters. Most managers cannot tell the difference between a great design and a horrible design, so they will never promote or reward you based on architecture alone. However, if you treat the company’s money as your own, if you thoroughly design the project to find the most affordable and safest way of building the system, and if you flat out refuse any other course of action, the higher-ups will notice. By showing the utmost respect for the company’s money, you will earn their respect, because respect is always reciprocal. Conversely, people do not respect those who are disrespectful toward them. When you are accountable for your actions and decisions, your worth in the eyes of top management will drastically increase. If you repeatedly meet your commitments, you will earn the trust of the top brass. When the next opportunity comes, they will give it to the one person whom they trust to be respectful of their time and money: you.
This advice is drawn from my own career. Before I was 30 years old, I led the software architecture group of a Fortune 100 company in Silicon Valley, the most competitive place in the world for the software industry. My rise to the top had little to do with my architecture prowess (as discussed, that hardly ever amounts to much). I did, however, always bundle my system design with project design, and that made all the difference. In my mind, the company’s money was my money.
General Guidelines
Do not design a clock.
After years of disappointments and disillusion from software projects, those exposed for the first time to the ideas of project design are captivated by its precision and fascinated by its engineering principles. They are tempted to go after every last digit in every calculation and to refine every last assumption and estimation, thereby missing the point of sound project design. The most important thing that project design enables is making educated decisions about the project: whether to proceed at all, and if so, under which option. The project design option you choose will always differ from reality, and the actual project execution will be similar, but not quite what you have designed. The project manager must follow up on the project design by frequently tracking the project against the plan and taking corrective actions (see Appendix A).
Even the best project design solution just gives you a fighting chance during execution—nothing more. Note that “best” in this context means a design that is the most calibrated to what your team can produce (in terms of time, cost, and risk), not necessarily the optimal design.
Think of project design as a sundial, rather than a clock. A sundial is an extremely simple device (a vertical stick in the ground), but it is good enough to tell the time down to the minute (if you know the date and the latitude). A clock can tell the time down to the second, but it is a far more intricate device in which every internal detail has to be perfectly tuned for it to work at all. By analogy, your project design effort needs to be only good enough to tell roughly to what it is possible to commit. Optimal precise solutions where every last detail is perfectly aligned are nice, but a normal, doable solution is a must.
Architecture Versus Estimations
Never design a project without a solid architecture that encapsulates the volatilities.
Without the correct system architecture, at some point the system design will change. Those changes mean that you will be building a different system which will void the project design. Once that happens, it does not matter if you had the best project design at the beginning of the project. As prescribed in the first part of the book, you need to invest the time to deal with the volatilities, whether or not you use the structure of The Method to do so.
Unlike architecture, estimations and specific resources are secondary to a good project design. The topology of the network (which derives from the architecture) dictates the duration of the project, not the capabilities of the developers or, to a point, the variation in individual estimations. Estimations that differ significantly from reality could affect the project drastically. However, as long as the estimation is more or less correct, then it does not matter if the real duration involved is somewhat larger or smaller. With a decent-size project you will have dozens of activities whose individual estimations may be off in either direction. Overall, these offsets will tend to cancel each other. The same is true with developers’ capabilities. It makes a huge difference if you have the world’s worst or best developer, but as long as you have decent developers, things will even out. It is more important to be creative in coming up with project design ideas, to recognize constraints, and to work around pitfalls than it is to get every estimation exactly right.
Design Stance
You should not apply the ideas in this book dogmatically.
You should adapt the project design tools to your particular circumstances without compromising on the end result. This book aims to show you what is possible, to trigger your natural curiosity, to encourage you be creative, and to lead.
When possible, do not design a project in secret. Design artifacts and a visible design process build trust with the decision makers. If stakeholders ask, educate them about what you are doing and why you are doing things this way.
Optionality
Communicate with management in Optionality.
When you engage with management, speak the language I call Optionality: succinctly describing the options from which management can choose, and enabling objective evaluation of these options. This is very much aligned with a core concept in project design: There is no “the” project. There are always multiple options for building and delivering any system. Each option is some viable combination of time, cost, and risk. You should therefore design several such options from which management may chose.
The essence of good management is choosing the right option. Moreover, giving people options empowers them. After all, if there is truly no other option, then there is also no need for the manager. Managers who lack options from which to choose will be forced to justify their existence by introducing arbitrary options. Without a backing project design, such contrived options always have poor results. To avoid this danger, you must present management with a set of viable project design options, preselected by you. For example, Chapter 11 investigated a total of 15 project design options, but the corresponding SDP review had only 4 options.
That said, do not overdo Optionality. Giving too many options upsets people, a predicament known as the paradox of choice.1 This paradox is rooted in the fear of missing out on some better option you did not choose, even if the option you did choose was good enough.
1. Barry Schwartz, The Paradox of Choice: Why More Is Less (Ecco, 2004).
Here are my guidelines on how many options to present:
Two options is too few—too close to no options at all.
Three options is ideal; most people can easily choose between three options.
Four options is fine as long as at least one of them (and maybe two) is an obvious mistake.
Five options is too many options, even if they are all good options.
Compression
Do not exceed 30% compression.
Whichever way you choose to compress the project, a 30% reduction in schedule is the maximum compression you will likely see when starting from a sound normal solution. Such highly compressed projects will probably suffer from high execution and schedule risk. When you first begin using the project design tools and building competency within your team, avoid solutions with more than 25% compression.
Understanding the Project
Always compress the project, even if the likelihood of pursuing any of the compressed solutions is low.
Compression reveals the true nature and behavior of the project, and there is always something to gain by better understanding your own project. Compression allows you to model the project’s time–cost curve, and obtaining formulas for cost and risk is helpful when you are required to assess the effect of schedule changes. It is immensely valuable to be able to quickly and decisively determine the likely consequence of a change request. The alternative is gut feel and conflict.
Even if you suspect that an incoming request is unreasonable, saying “no”—especially to a person of authority and power—is not conducive to your career. The only way to say “no” is to get “them” to say “no.” By showing the quantified effects on schedule, cost, and risk, you immediately bring to the surface what before you could only intuit, enabling an emotion-free, objective discussion. In the absence of numbers and measurements, anything goes. Ignorance of reality is not a sin, but malpractice is. If decision makers are aware of numbers that contradict their commitments to customers and still persist with those commitments, they are perpetrating fraud. Because such liability is unacceptable, in the presence of hard numbers, they will find ways of rescinding their commitments or changing previously “unchangeable” dates.
Compressing with Top Resources
Compress with top resources carefully and judiciously.
When relying on top resources, proper project design is essential to know where to apply them. As appealing as it may be, compressing with top resources may backfire. To begin with, top talent is typically scarce, so the top resources you require to meet your commitments may not be available. Waiting for them creates delays and defeats the purpose of the compression. Even when available, top resources may make things worse because leveraging them to compress the critical path could make a new critical path emerge. Since you assign your resources based on float and capabilities, you now run the risk that the worst developers will be working on that new critical path.
Even when assigned to formerly critical activities, the top resources often are idle, waiting for other activities and developers in the project to catch up. This reduces the project’s efficiency. To avoid this situation, you may need a larger team that can compress other paths by working in parallel. Such an increase in team size will reduce efficiency and increase the cost. Finally, compressing using top resources often requires two or more such heroes to compress multiple critical or near-critical paths to see any benefit from the compression.
When assigning top resources, you should avoid doing so blindly (such as assigning the top resource to all current critical activities). Evaluate which network path would benefit the most from the resources, determine the effect on other paths, and even try combinations across chains. You may have to reassign the top resource several times based on the changes to the critical path. You should also look at activity size as well as the criticality. For example, you may have a large, noncritical activity with a high level of uncertainty that could easily derail the project. Assigning the top resources there will reduce that risk and ultimately help you meet your commitments.
Trimming the Fuzzy Front End
The easiest way of compressing the project is to trim the project’s initial activities, the fuzzy front end.
While no project can be accelerated beyond its critical path, no such rule applies to the front end. Look for ways of working in parallel at the front end on preparatory or evaluation tasks. This would compress the front end (and thus the project) without any change to the rest of the project. For example, Figure 14-1 shows a project (the upper chart) with a long front end. The front end contains a few crucial technology and design choices that the architect had to settle before the rest of the project could proceed. By hiring a second architect as a contractor for two of these decisions, the front end duration was reduced by a third (the lower chart in Figure 14-1).
Figure 14-1 Trimming the front end with a second architect
Planning and Risk
Preempt the unforeseen with float.
The risk index indicates whether the project will break down when it hits the first obstacle or whether the project can leverage that obstacle to introduce refinements, adapting to make the design a better approximation of reality. Having sufficient float (indicated by the low risk) gives you a chance to thrive in the face of the unforeseen.
I also find that the project’s need for float is as much psychological as it is physical. The physical need is clear: You can consume float to handle changes and shift resources. The psychological need is the peace of mind of all involved. In projects with enough float, people are relaxed; they can focus and deliver.
Behavior, Not Values
Chapter 10 suggested 0.5 as the minimum decompression target and 0.3 as the minimum risk level. As valuable as these risk guidelines are, when examining the risk curve of the project you should be aware that behavior is more important than values. When decompressing the project, look for the risk tipping point rather than the 0.5 value. Something may be skewing the whole risk curve higher or lower, but there could still be a tipping point for risk. This is especially the case when the normal solution already has low risk. You may need to decompress the project, but you do that by using the tipping-point behavior.
Design of Project Design
Project design is a detailed-oriented activity. You should treat the act of project design as just another intricate effort that you need to map out and design. In other words, you need to design project design, and even use the tools of project design when doing so. You begin this design effort with the system design and proceed to designing the project as a single continuous design effort.
To help you get started, here is a list of common design activities:
Gather core use cases
Design the system and produce call chains and a list of components
List noncoding activities
Estimate the duration and required resources for all activities
Estimate the overall project using broadband and/or a tool
Design the normal solution
Explore the limited-resources solution
Find the subcritical solution
Compress using top resources
Compress using parallel work
Compress using activity changes
Compress to minimum duration
Perform throughput, efficiency, and complexity analysis
Produce the time–cost curve
Decompress the normal solution
Rebuild the time–cost curve
Compare the time–cost curve to the overall project estimation
Quantify and model risk
Find inclusion and exclusion and risk zones
Identify viable options
Prepare for SDP review
While some of these activities could take place in parallel to other activities, the activities in system design and project design do have interdependencies. The next logical step is to design your project design using a simple network diagram and even calculate the total duration of the effort. Figure 14-2 shows such a network diagram of the design of project design. You can identify the likely critical path using typical durations for the activities. If a single architect is designing the project, then the diagram will actually be a long string. If the architect has someone helping, or if the architect is waiting for some piece of information, the diagram suggests activities to do in parallel.
Figure 14-2 Design of project design
Activities 6, 7, 8, 9, 10, 11, and 12 in the list (shown in blue in Figure 14-2) are specific project design solutions. You can further break down each of those into this list of tasks:
Discover planning assumptions
Gather staffing requirements
Review and revise the list of activities, estimations, and resources
Decide on dependencies
Modify the network to accommodate constraints
Modify the network to reduce complexity
Assign resources to activities and rework the network
Draw the network diagram
Evaluate the shallow S curve
Evaluate the staffing distribution chart
Modify the planning assumptions and rework the network
Calculate cost elements
Analyze floats
Calculate risk
In Perspective
In any system it is important to distinguish between effort and scope. The architecture in a software system must be all-encompassing both in scope and in time. It must include all required components, and it must be correct at the present time and in the far future (as long as the nature of the business does not change). You must avoid the very expensive and destabilizing changes that are the result of a flawed design. When it comes to the effort, the architecture should be very limited. Part 1 of this book explained how you can come up with a solid, volatility-based decomposition in a few days to a week, even for a large system. Doing so requires knowing how to do things correctly, but it is certainly possible with practice and experience.
Compared to the architecture, design—especially the services detailed design or Clients user interface—is both more time-consuming and limited in scope. It may take several weeks to refine the detailed design of just a few interacting services.
Finally, coding is the most time-consuming and the most limited in scope. Developers should never code more than one service at a time, and they will spend considerable time testing and integrating each service as well.
Figure 14-3 illustrates in a qualitative manner the scope versus effort for a software project. You can see that scope and effort are literally inverses of each other. When something is wider in scope, it is narrow in effort, and vice versa.
Figure 14-3 Scope versus effort in a software system
Subsystems and the Timeline
Chapter 3 discusses the concept of mapping subsystems to vertical slices of the architecture. In a large project you may have several such subsystems. These subsystems should be fairly decoupled and independent from one another. Each subsystem has its own collection of activities, such as detailed design and construction. In a sequential project, the subsystems are consecutive, as shown in Figure 14-4.
Figure 14-4 Sequential project life cycle
Note that the subsystems are always designed and constructed in the context of the existing architecture. The effort allocation in Figure 14-4 is still that of Figure 14-3.
You may be able to compress the project and start working in parallel. Figure 14-5 shows two views of concurrent subsystem development aligned against the timeline.
Figure 14-5 Parallel project life cycles
Which parallel life cycle you choose depends on the level of dependencies between the subsystems of the architecture. In Figure 14-5, the life cycle on the right staggers the subsystems to overlap on the timeline. In this case, you can start building a subsystem once the implementation of the interfaces of the subsystem on which it depends are complete. You can then work on the rest of the subsystem in parallel to the previous one. You can even create fully parallel pipelines like the layout on the left of Figure 14-5. In this case, you build each subsystem independently of and concurrently with the other subsystems with minimum integration.
The Hand-Off
The composition and makeup of the team has a significant effect on project design. Here, team composition refers specifically to the ratio of senior to junior developers. Most organizations (and even individuals) define seniority based on years of experience. The definition I use is that senior developers are those capable of designing the details of the services, whereas junior developers cannot. Detailed design takes place after the major architectural decomposition of the system into services. For each service, the detailed design contains the design of the service public interfaces or contracts, its messages and data contracts, and internal details such as class hierarchies or security.
Note the definition of senior developers is not developers who can or know how to do detailed design. Instead, senior developers are those capable of doing detailed design, once you show them how to do so correctly.
Junior Hand-Off
When all you have are junior developers, the architect must provide the detailed design of the services. This defines the junior hand-off between the architect and the developers. The junior hand-off disproportionally increases the architect’s workload. For example, in a 12-month project, some 3 to 4 months of the overall duration could be spent simply on detailed design.
The architect’s detailed design work can take place in the front end or while developers are constructing some of the services. Both of these options are bad.
Coming up with the correct details of all the services up front is very demanding, and seeing in advance how all the details across all services mesh together sets a very high bar. It is possible to design a few services up front, but not all of them. The real problem is that detailed design in the front end simply takes too long. Management is unlikely to understand the importance of detailed design and will cringe at the prospect of extending the front end to accommodate it. Consequently, management will force handing off the architecture to junior developers and doom the project.
Designing the services on the fly, in parallel to the developers who are constructing services that the architect has already designed, could work. However, overloading the architect with detailed design makes the architect a bottleneck and may considerably slow down the project.
Senior Hand-Off
Senior developers are essential to address the detailed design challenge. If not already capable of doing so, with modest training and mentoring senior developers can perform the detailed design work, allowing for a senior hand-off between the architect and the developers.
With a senior hand-off, the architect can hand off the design soon after the SDP review, providing only a general outline of the services using gross terms for interfaces or just suggesting a design pattern. The detailed design now takes place as part of each individual service, and the architect just needs to review it and amend as needed. In fact, the only reason to pay for additional senior developers is to enable the senior hand-off. The senior hand-off is the safest way of accelerating any project because it compresses the schedule while avoiding changes to the critical path, increasing the execution risk, or introducing bottlenecks. Since shorter projects will cost less, it follows that senior developers actually cost less than junior developers.
Senior Developers As Junior Architects
The problem with the senior hand-off is the scant availability of senior developers. You may have one or two of them, and perhaps three, but not an entire team. If that is your situation, you should not use your one or two senior developers as developers. Instead, change the process to have these senior developers do mostly detailed design work. Figure 14-6 shows what that process flow looks like.
Figure 14-6 Working in parallel with junior architects
The architect must provide a comprehensive architecture, as discussed in Part 1 of this book. The architecture will not change during the life of the system, and the construction is always done in the context of that architecture. Producing the architecture still takes place at the project’s front end. The front end may also contain the detailed design of the first handful of services. This detailed design is both done by the senior developers and used as a training and learning opportunity under the guidance of the architect. This, in effect, turns the senior developers into junior architects.
Once the detailed design of the services is complete, the junior developers can step in and construct the actual services. However, any design refinement, as trivial as it may be, requires the junior developers to consult with the senior developer who designed that service. Once finished with each service construction, the junior developers proceed to code review with the senior developers (not their junior peers), followed by integration and testing with other junior developers. Meanwhile, the senior developers remain busy with the detailed design of the next batch of services. Each design is reviewed with the architect before hand-off to the junior developers.
Working this way is the best and only way of mitigating the risks of the junior hand-off. Clearly, it also requires meticulous project design. You must know exactly how many services you can design in advance and how to synchronize the hand-offs with the construction. You must also add explicit service detailed design activities and even additional integration points to address the risk of extracting the detailed design out of the services.
In Practice
As with system design, when it comes to project design, you must practice. The basic expectation of professionals—from lawyers to doctors to pilots—is that they know their trade by heart and that they keep at it. Under fire, everybody sinks to their level of training. Unfortunately, unlike system design, hardly any software architect is even aware of project design or is trained in it, even though project design is both critical to success and, as discussed in Chapter 7, the software architect’s responsibility.
Compounding the need for project design practice are two additional issues. First, project design is a vast topic. This book covers the core body of knowledge required of modern software architects, both system design and project design. In terms of its page count, project design outweighs system design by 2:1. You should now have a feeling that you are peering into a deep rabbit hole. You cannot internalize and correctly use the concepts of this book without training and practice. Figuring out project design by designing real projects on the job not only is asking for trouble, but also defies common sense. Would you like to be the first patient of a doctor fresh out of medical school? Would you like to fly with a new pilot? Are you proud of your first program?
Second, project design, in many cases, produces non-intuitive results. You will have to practice not just to master a massive body of knowledge, but also to develop a new intuition. The good news is that project design skills can be acquired, as is evident by the swift and marked improvement in the quality of the project designs and the success rate of those who do practice.
Chapter 2 emphasized the importance of system design practice. Always combine practice in designing a system and practice in designing the project to build it. Start with just a simple normal solution. Train until you are comfortable with normal solutions for your practice systems. Then, build from there to find the best solution as far as schedule, cost, and risk.
Examine your own past projects. With the advantage of hindsight, try to reconstruct the project design that took place and contrast it with what should have been done. Identify the planning assumptions, the classic mistakes, and the right decisions. Prepare for an SDP review by listing all the solutions you would have proposed if you could. Look at your current project. Can you list the activities, come up with the correct estimations based on what the team is presently doing, and calculate the true schedule and cost? What is the current risk level? What is required to decompress the project? What level of compression is feasible?
When you think you have got it right, raise the bar again and find ways of improving these designs. Never rest on your laurels. Develop new techniques, refine your own style, and become a passionate expert and advocate of project design.
Debriefing Project Design
Debriefing is underutilized in the software industry, even though it is an effective technique with fantastic ROI. A debrief of your project design effort and results is important. It provides a way to share lessons learned across projects and roles so that each person can learn from the experience of others. All it takes is self-reflection, analysis, and the desire to improve. You should debrief each and every one of your projects and make the debriefing part of your software development life cycle. You should debrief each project as a whole and debrief each subsystem or milestone as well. The more you make debriefing part of your routine, the more likely you are to actually debrief and benefit from it.
The debrief topics depend on what you deem important and what needs improvement. They may include the following considerations:
Estimations and accuracy. For each activity, ask yourself how accurate the initial estimation was when compared with the actual duration, and how many times you had to adjust the estimations and in which direction. Is there a noticeable pattern that you could incorporate in future projects to improve the estimations? Review the initial list of activities to see what you missed and what was superfluous. Calculate the extent to which the errors in the estimations canceled each other out.
Design efficacy and accuracy. Compare the accuracy of the initial broad project estimation with the detailed project design and the actual duration and cost. How accurate was your assessment of the throughput of the team? Was risk decompression necessary, and if so, was it too much or too little? Finally, was the compressed project doable, and how did the project manager and the team handle complexity?
Individual and team work. How well did the team members work as a team or individually? Were there any bad apples? Can you make the team more productive in the future by using better tools or technology? Did the team communicate issues in a timely manner? How well did the team members understand the plan and their role in it?
What to avoid or improve next time. Compile a prioritized list of all the mistakes or troubles encountered across people, process, design, and technology. For each item, identify how you could have detected it sooner or avoided it in the first place. List both actions that caused problems and actions that should have taken place. You should also include near-misses that did not end up causing harm.
Recurring issues from previous debriefs. One of the best ways to improve is to avoid past mistakes and prevent known problems from happening. It is detrimental to everyone when the same mistakes appear in project after project. There is likely a very good reason why the same problem is recurrent. Nonetheless, you must eliminate recurring mistakes in spite of the challenges.
Commitment to quality. What level of commitment to quality was missing or present? How intimately related was it to success?
It is important to debrief even successful projects that have met their commitments. You must know if you have succeeded just because you were lucky or because you had a viable system and project design. Even when the project is a success, could you have done a better job? What should you do to sustain the things you did right?
About Quality
In the abstract, everything in this book is about quality. The very purpose of having a sound architecture is to end up with the least complex system possible. This provides for a higher-quality system that will be easier to test and maintain. There is no denying it: Quality leads to productivity, and it is impossible to meet your schedule and budget commitments when the product is rife with defects. When the team spends less time hunting problems, the team spends more time adding value. Well-designed systems and projects are the only way to meet a deadline.
With any software system, quality hinges on having a project design that includes the crucial quality-control activities as an integral part of the project. Your project design must account for the quality control activities both in time and in resources. Do not cut corners if your project design goal is to build the system quickly and cleanly.
A side effect of project design is that well-designed projects are low-stress projects. When the project has the time and the resources it requires, people are confident in their own ability and in their project’s leadership. They know the schedule is doable and that every activity is accounted for. When people are less stressed, they pay attention to details, and things do not fall between the cracks, resulting in better quality. In addition, well-designed projects maximize the team’s efficiency. This contributes to quality by allowing the team to more readily identify, isolate, and fix defects in the least costly way.
Your system and project design effort should motivate the team to produce the highest-quality code possible. You will see that success is addictive: Once people are exposed to working correctly, they take pride in what they do and will never go back. No one likes high-stress environments afflicted by low quality, tension, and accusations.
Quality-Control Activities
Your project design should always account for quality-control elements or activities. These include the following:
Service-level testing. When estimating the duration and effort of each service, make certain the estimation includes the time needed to write the test plan for the service, to run the unit test against the plan, and to perform integration testing. If relevant, add the time to roll the integration testing into your regression testing.
System test plan. The project must have an explicit activity in which qualified test engineers write the test plan. This includes a list of all the ways to break the system and prove it does not work.
System test harness. The project must have an explicit activity in which qualified test engineers develop a comprehensive test harness.
System testing. The project must have an explicit activity in which the software quality-control testers execute the test plan while using the test harness.
Daily smoke tests. As part of the indirect cost of the project, on a daily basis, you must do a clean build of the evolving system, power it up, and (figuratively) flush water down the pipes. This kind of smoke test will uncover issues in the plumbing of the system, such as defects in hosting, instantiation, serialization, connectivity, timeouts, security, and synchronization. By comparing the result with the previous day’s smoke test, you can quickly isolate plumbing issues.
Indirect cost. Quality is not free, but it does tend to pay for itself because defects are horrendously expensive. Make sure to account correctly for the required investments in quality, especially when it is in the form of indirect cost.
Test automation scripting. Automating the tests should be an explicit activity in the project.
Regression testing design and implementation. The project must have comprehensive regression testing that detects destabilizing changes the moment they happen across the system, subsystems, services, and all possible interactions. This will prevent a ripple effect of new defects introduced by fixing existing defects or simply making changes. While executing regression testing on an ongoing basis is often treated as an indirect cost, the project must contain activities for writing the regression testing and its automation.
System-level reviews. Chapter 9 discussed the need to engage in extensive peer reviews at the service level. Since defects can occur anywhere, you should extend reviews to the system level. The core team and the developers must review the system requirements spec, the architecture, the system test plan, the system test harness code, and any additional system-level code artifacts. Both with service and system reviews, the most effective and efficient reviews are structured in nature2 and have designated roles (moderator, owner, scribe, reviewers), as well as follow-ups to ensure the recommendations are applied across the system. At a minimum, the team should hold informal reviews that involve walking through these artifacts with one or more peers. Regardless of the method used, these reviews require a high degree of mutual involvement along with team spirit of commitment for quality. The reality is that delivering high-quality software is a team sport.
2. https://en.wikipedia.org/wiki/Software_inspection
This list is only partial. The objective here is not to provide you with all the required quality-control activities, but rather to get you to think about all the things you must do in your project to control quality.
Quality-Assurance Activities
Your project design should always account for quality-assurance activities. Previous chapters (especially Chapter 9) have already discussed quality assurance, but you should add the following quality assurance activities to your process and your project design:
Training. It costs significantly less (and is much better quality-wise) if your developers do not attempt to figure out new technologies on their own. By sending the developers to training (or bringing the training in-house), you instantly eliminate many defects due to learning curves or lack of experience.
Authoring key SOPs. Software development is so complex and challenging that nothing should be left to chance. If you do not have standard operating procedures (SOPs) for all key activities, devote the time to researching and writing them.
Adopting standards. Similar to SOPs, you must have a design standard (see Appendix C) and a coding standard. By following best practices, you will prevent problems and defects.
Engaging QA. Actively engage a true quality-assurance person. Have that person review the development process, tune it to assure quality, and create a process that is both effective and easy to follow. This process should support investigation and elimination of the root cause of defects or, even better, should proactively prevent problems from happening in the first place.
Collecting and analyzing key metrics. Metrics allow you to detect problems before they happen. They include development-related metrics such as estimation accuracy, efficiency, defects found in reviews, quality and complexity trends, as well as run-time metrics such as uptime and reliability. If required, devise the activities to build the tools that collect the metrics, and account for the indirect cost of collecting and analyzing them on a regular basis. Back it up with a SOP that mandates acting on abnormal metrics.
Debriefing. As described in the previous section, debrief your work as you progress, and debrief the project as a whole once it is completed.
Quality and Culture
Most managers do not trust their teams. Those managers have experienced too many disappointments, and they see little or no correlation between the effort the team expends and the desired results. Consequently, the managers resort to micromanaging everything. This is a direct result of a chronic deficit in trust. The developers respond to the micromanagement with frustration and apathy, and lose any remaining shred of accountability. This degrades trust even further, vindicating the sentiments of the managers.
The best way of turning this dynamic around is by infecting the team with a relentless obsession for quality. When totally committed to quality, the team will drive every activity from a perspective of quality, fixing the broken culture and creating an atmosphere of engineering excellence. To reach this state, you must provide the right context and environment. In practice, this means doing everything in this book—and more.
The result will be a transition from micromanagement to quality assurance. Allowing and trusting people to control the quality of their work is the essence of empowerment. Once this is in place, you will learn that quality is the ultimate project management technique, requiring very little management while maximizing the team’s productivity. The managers now focus on facilitating the correct environment for the team, trusting the team to produce impeccable software systems, on time and on budget.