Lean Software Systems Engineering for Developers: Managing Requirements, Complexity, Teams, and Change Like a Champ

By Doug Durham and Chad Michel

Graduate to the next level of your software development career, learning the tools you need to successfully manage the complexity of modern software systems.

Whether you are a developer at a small software company, or one of many developers at a large enterprise, your success directly correlates to the ability of your development team to rapidly respond to change. What makes this task challenging in today’s world, is that the technical challenges we as developers strive to overcome are becoming increasingly more complex. We have to consider many more options when it comes to things like requirements, solution hosting, support, pace of change, and generally with less time and warning.

A good developer knows that it is critical to manage every aspect of software development from soup to nuts, and understands that when details and decisions are left to chance, outcomes can be negatively impacted. Poor planning can result in increased errors, substandard quality, budget andschedule overruns, and result in the ultimate business failure, dissatisfied customers, and stakeholders.

This book will help you put on the lenses of a software engineer. You will come away with an understanding of how to view the entire spectrum of the software development process, learn valuable concepts, and apply these principles through meaningful examples, case studies, and source code.

What You Will Learn

• Move beyond being a programmer to being a professional software engineer
• Spend more time doing software development; minimize time spent dealing with ineffective or inadequate processes
• Reduce errors in judgment and provide predictable outcomes, while still maintaining agility and responsiveness using Lean and Agile practices
• Know the steps you can take to ensure a shared understanding among stakeholders
• Discover tools to validate user experience early and often to minimize costly re-work
• Develop software designs and architectures that enable long-term business agility
• Implement patterns and processes that result in “falling into the pit of success” instead of into the “pit of failure”
• Adopt processes and patterns that will result in pervasive “institutionalized” quality
• Understand the necessity of redefining the essential role of technical leadership to ensure team maturity and growth

Who This Book Is For

Software developers and team leaders who have struggled to implement design and development best practices due to lack of team resources, in-depth knowledge, or experience, and want a book designed to provide the confidence and foundational skills needed to achieve success

• Language: English
• Publisher: Apress
• Release date: Jun 12, 2021
• ISBN: 9781484269336

Book preview

© The Author(s), under exclusive license to APress Media, LLC, part of Springer Nature 2021

D. Durham, C. MichelLean Software Systems Engineering for Developershttps://doi.org/10.1007/978-1-4842-6933-6_1

1. Focusing on Software Development Outcomes Instead of Outputs

Doug Durham¹   and Chad Michel¹

(1)

Lincoln, NE, USA

Introduction

Imagine landscaping your yard is your hobby, and you would like to have a small storage building to keep all of your garden and yard tools organized and stored. You want to be the envy of your neighbors, so you take the opportunity to create something that will stand out. You spend an hour or two drawing something that demonstrates the style of the garden shed and its dimensions. Maybe something like the plans shown in Figure 1-1.

../images/504026_1_En_1_Chapter/504026_1_En_1_Fig1_HTML.jpg

Figure 1-1

Garden shed plans

Let’s say the design ends up being a 10’ x 20’ building. Given that you are more of a gardener than a carpenter, you reach out to some professionals to help you build this shed. You call your buddy, who is a carpenter, and he connects you with an electrician, plumber, concrete specialist, and painter who will help with the project. (I did say this needs to be the envy of your neighborhood, right?)

To kick off the project, you invite them over to collaborate on the drawings. You explain what you are looking for, and they ask the requisite questions about paint, windows, electrical outlet locations, etc., suggesting a few design improvements along the way. They estimate it will take them several days, maybe even a week, to finish the shed. Anxious to get started, you let them know that you are readily available to answer any questions and check in with them daily.

Fast-forward to the reveal of the finished garden shed. Ask yourself this: How likely do you think it will be that you will be happy with the garden shed, despite the fact there was very little planning and communication between you, as the designer/stakeholder, and the construction team? I suspect most, if not all of you would assume that the finished product would turn out great and your neighbors would, indeed, be duly impressed, just as you’d hoped. This is a very reasonable assumption. Even if the garden shed did turn out to disappoint, you can probably start over or make some changes without adding much cost or time.

Now, let’s take it to the next level. Instead of building a garden shed, let’s say you want to build an actual home. You go through the same process of spending a few hours making some drawings with dimensions and details you felt were important. You assembled your team of skilled craftsmen to review your drawings, and they ask more questions, then make more suggestions that improve (and even fix) some of your drawings and designs. They probably seem a little nervous about taking on a project like this given the size of the effort and the relatively small number of drawings (see Figure 1-2) and details being provided, but they finally agree to do it. They give you an estimate that you feel seems a little low given what you are envisioning, but you are not the expert, so you just assume that they know what they are doing.

../images/504026_1_En_1_Chapter/504026_1_En_1_Fig2_HTML.jpg

Figure 1-2

Sketch for a house design

As with the other scenario, you let them know that you are available for any questions that might come up and that you will be checking in with them on a weekly basis to see how things are going.

Fast-forward to the completion of the finished house. Consider this, how likely is it that you will be happy with the house? I suspect most, if not all of you, would have found the process of building the house frustrating and the finished product not what you envisioned. This is a very reasonable assumption.

Let’s consider why that is and take a moment to hypothesize about where the project might have gone wrong:

You might have assumed that the project would have started out fine as the foundation and other utilities work was done. After all, it does not really look like a house at this point and you are no expert, so what the contractors are doing is probably correct.

Many decisions were made without your input and were clearly wrong.

Some decisions were made without your input that actually improved the design of the house.

Some of the contractors independently made choices that did not match your vision and resulted in a lot of rework.

Other contractors did follow your vision without question, but they were bad design decisions and ultimately needed to be reworked.

In the end, you decide that you should have been more involved, you should have provided more details, you should have hired an architect and general contractor to ask the questions you didn’t know to ask. Too much was left to chance and, as a result, your project took much longer, the costs greatly exceeded your budget, and you had to make so many compromises along the way that in the end you aren’t satisfied with how the house looks and feels. You may even decide to sell the house and try again, thinking that you’ll do it right next time.

Tackling complex projects the same way we tackle smaller, simpler projects will not work. As you can probably assume, while garden sheds might follow a process like what was described, when it comes to building houses, this is not the way these types of projects are executed. The most common scenario for house construction is to have a general contractor. It would be extremely uncommon to build a house without a complete set of architectural drawings that the general contractor and the team reference when constructing it (Figure 1-3).

../images/504026_1_En_1_Chapter/504026_1_En_1_Fig3_HTML.jpg

Figure 1-3

Detailed house design

The general contractor is also making sure that what is being built matches the plans and will be the person to go back to the owner with questions or suggestions. While the construction of the house is likely the largest overall expense, there is significant time and effort put into the planning portion that occurs prior to commencing construction. Clearly, building a house is a complicated endeavor, and leaving things to chance is a sure-fire way to run up the cost of the project and/or end up with a house that disappoints.

Modern software development is much the same way. When we think about the type of challenges we are faced with today and the types of problems we are trying to solve with software, is it building a garden shed or a home? Or, is the project complexity more akin to building a space station?

Using that analogy, let’s think about how your projects are managed. Think about a project, small or complex, that you have worked on in the past. What was missing? Were your processes ill-defined or inconsistently followed? How much of the outcome of your projects was left to chance? Why was this? Did it make sense?

Too often, we are more focused on whether outputs are being created and not on whether the outcome of those outputs is meeting our needs and expectations. Yes, the house is being built and it has a lot of the features we were looking for. And true, there was an output of a house from all of this effort. But equally true is that the outcome of the process was unsatisfactory. Focusing on outcomes and not just outputs will help ensure that the efforts we are making and the processes we are following will align with our desired outcomes. In the end, the less we leave to chance the more successful we will be in achieving these desired outcomes.

Software Engineering vs. Software Development

Let’s take a step back and examine the way we view the software development profession. We have all encountered people who call themselves software engineers instead of software developers or programmers. Software engineer sounds more formal and impressive compared to software developer. You might think that getting the title of software engineer is a result of some formal education and/or some accredited evaluation of the depth and breadth of your skills. Sadly, the titles people are given in this industry are seemingly arbitrary and are often selected to make a job sound more impressive or to differentiate ourselves from others in the industry. Could you imagine this happening in other career fields? What if medical providers were allowed to pick their titles?

Imagine interviewing a variety of professionals across a broad spectrum of fields to understand what they do and what it means to be a doctor, or a lawyer, or a civil engineer. You might ask about their responsibilities, behaviors, and practices. It is safe to assume that you will get a consistent answer from all of the people you interview in each respective profession. Doctors are trained with similar methods and are exposed to a similar body of knowledge that they are trained on how to apply. Sure, they differ in the level of skill and their specialization and even in some of their techniques, but if you went to see a couple of orthopedic surgeons for an injury, you are likely to have a similar outcome regardless of whom you choose. These professions often include certification processes to ensure a minimum competency. The result is that there is a level of confidence and trust that the public has in these professions that (a) they are trained to a certain, consistent level, (b) they are competent practitioners of their profession, and (c) they leave little or nothing to chance. In fact, when someone from one of these professions fails to meet these expectations, it often makes the news or involves some legal processes. What if we, in the software development industry, were held to the same standards as doctors, lawyers, and engineers? Should we be held to similar standards? Wouldn’t it be an