Perfect Software Development
This book is 91% complete
Last updated on 2020-06-19
About the Book
Why I Wrote This Book
Looking back at my career in software development, I can see how I ended up writing a book like this. It addresses the gaps that I saw in the industry, and it reflects who I am - a software development perfectionist (bear with me, I will prove that this is not a bad thing at all).
This work is an attempt to fix the problems that always challenged me. I know that those same issues worry many others too.
At every job I worked, I (as a developer) was bogged down by non-readable code, non-practical architectures, a vast amount of defects, unclear requirements, unavailable domain experts, monolithic codebases, long deployments (releases), and so on.
The business side was not happy either. Domain experts complained about things like the quality of software, the way it worked, its capacity to handle more users, the cost of developing it, and so on.
I honestly believe that I have answers to all these challenges for those who want to solve them.
I care because I experience these same problems myself on a daily basis, and I address them successfully where my capacity allows me to do so. My approach is tried out for many years, and it's time to help others fix these issues too.
Below I present a couple of fragments from my past that formed my reasons to start writing. I hope that some readers will recognize their own experience or personality between the lines. This narrative will also explain what kinds of problems we will be solving along the way.
On my first job, I was the only developer on the team. I had the freedom to write code in any way I wanted, and that seemed to be the perfect environment to thrive in success.
I developed many applications and components from scratch, and I enjoyed the freedom of improvising in code. Everything was going smoothly until the codebase grew to the point that I had a hard time working with it. I almost wanted to start it all over again.
It turns out that many developers struggle with the same symptoms throughout their career paths. How can the code that was written by ourselves bite us back? There must be something wrong with what we do, don't you agree?
Therefore, we will learn how to write code that does not become our problem shortly after we authored it.
On my second job, I was not the only one on the team, so I had a chance to read code written by other developers too. It was a rather complex banking domain, and I needed to know it well to keep the job. When such a challenge faces us, we realize that the codebase can either be our friend or enemy, depending on whether it helps or blocks us from the goal.
I read a lot of code, but it did not give me any knowledge about the domain. Instead, it confused me more and more. I thought it was just me who couldn't follow code written by others. I explained it as if the code is not supposed to be understood by people, because it's written just for the machine to interpret. That was a naive thought. We are humans in the first place, so we should write code for humans. Computers will understand code no matter how we write it. So writing a program for them is a piece of cake. Try to write code that humans can understand - that's a challenge!
Therefore, we will learn how to write code that expresses valuable domain knowledge and helps in ramping up technical learners of the problem space.
I once worked on a project where developers had good knowledge of the problem space, and the specialists in the subject matter were accessible too. However, meetings went in silos instead of leveraging access to domain knowledge. First, a domain expert would describe a requirement in business terms; next, the conversation would transfer to the developers, while domain experts did not (or could not) participate in the discussion from that point on. Engineers would "interpret" the expectation using technical concepts, patterns, and frameworks, and would use their terminology and tools for implementation. Because of this intentional disconnect, the resulting solution was too technical and often had little or no relevance to how the business worked; instead, the solution added inconvenience and complexity for the business SMEs.
Therefore, we will learn how to write software that serves both developers and non-developers equally. It's time that we start helping the business instead of complicating their lives.
One more project comes to my mind. We could not focus on new feature development, because the defects were frequent. We had to jump on them as they appeared due to the high visibility of the application. We would fix defects, come back to our current sprint (iteration) backlog and we just knew that the next bug was hours, if not minutes, away. New feature development went slow and unorganized.
It's a terrible feeling when you can't focus on something and finish it without interruptions. It's like being tired in an airplane and trying to sleep, but a narrow seat and limited legroom do not let you relax completely. In those moments, you dream about a simple, comfortable bed.
It's crucial that we know how to avoid defects and allow ourselves to focus on a new feature development instead.
Although many consider bug-free software to be impossible, we will learn how to achieve it in real life.
I remember the tired face of an engineer who was tasked to support an application in a production environment. He didn't even write that software and didn't know all the intricacies inside the system. He had to keep bugging the actual development team with questions when a new kind of issue was discovered. He had a handbook full of troubleshooting steps for various types of symptoms that the application could produce. He was hesitant to contact the development team every time because the engineers were "cool guys" who had more important stuff to do than to support the application (written by them in the first place).
Nevertheless, the system under development was a nightmare to run and troubleshoot. Undoubtedly, the root cause was developers being unaware of the pain points of the production support and lacking the necessary skills for producing better software that would be easier to maintain. Would that be the case if developers had to run and support their solutions in a production environment instead of somebody else doing it for them?
To tackle the described problem, we will learn how to build software that works in a production environment without a dedicated production support team by distilling ways to develop better programs and maintain them in production with minimal to no cost.
Perhaps every developer has once been on a project where developing a new feature is like rocket science. The codebase is so complex that the implementation process is merely a trial and error activity, which involves making careful changes to several moving parts while finding more on the way. Such an increased level of complexity makes work and estimation very difficult.
When software development becomes a discovery process every single time, that hints at many problems in how the application is structured.
Therefore, we will learn about development and architecture techniques for building better software systems that are easier to develop and change.
Another side-effect that happens in the mentioned situation is a slowdown in development pace.
Therefore, we will study techniques to accelerate the software development process instead of slowing down.
I recently encountered a web application that was deployed to three servers to handle many parallel requests. Surprisingly to the engineers and their management, the system was struggling to serve only 100 simultaneous users. They tried to add more servers, but even more strangely, it only worsened the situation. As a last resort, the team rearchitected the application for better scalability, but that exposed other bottlenecks, and reaching more users became impossible. When such circumstances happen, you need to admit that the application is not scalable.
Therefore, we will learn how to build software that scales out horizontally by just adding more instances of the application when the number of users increases.
Various situations described above served as a foundation for the six primary pillars, upon which this book is built. We will go into more detail in the publication.
For now, I hope that most of you either recognized your experience or felt the urge to solve these kinds of problems at present or in the future.
Technical Lead, Change Agent, HHSC
Gomti Mehta provided invaluable feedback for the manuscript in progress with the preface and three other chapters in it.
Scrum Master, Agilist, CSM, PSM
Romana Stasiv is an active reviewer and editor of the book. She has provided invaluable feedback for every non-technical topic covered in the book.
- Copyright Notice
Part I. Introduction
- Chapter 1. History Behind Inefficient Monoliths
- Chapter 2. Why People Avoid Building Perfect Software
- Chapter 3. Software Development Perfectionism as a State of Mind
- Chapter 4. The Six Pillars of the Perfect Software
Part II. Crosscutting Concerns
- Chapter 5. Execution, Leadership, Management
- Chapter 6. Organizational Structure
- Chapter 7. Processes, Ongoing Efforts, Teams
- Chapter 8. Culture
- Chapter 9. Recruitment
Part III. Requirements Gathering, Analysis, Planning
- Chapter 10. Understanding Customer’s Needs
- Chapter 11. Organization’s Response to the Customer’s Needs
- Chapter 12. Requirements And Story Writing
- Chapter 13. Planning The Work
- Chapter 14. Carrying Out The Work
Part IV. Design And Architecture
- Chapter 15. Architecture As A Crosscutting Concern
- Chapter 16. Architecture In Analysis And Requirements Gathering
- Chapter 17. Architecture Body Of Knowledge
- Chapter 18. Architecture And Implementation
- Chapter 19. Architecture For Testable Systems
- Chapter 20. Architecture For Deployable Systems
- Chapter 21. Architecture For Maintainable Systems
Part V. Implementation And Coding
- Chapter 22. Crosscutting Concerns Related To Coding
- Chapter 23. Designing Code
- Chapter 24. Coding And Implementation
- Chapter 25. Testing Code
- Chapter 26. Deployment And Maintenance
Part VI. Testing And Quality Assurance
- Chapter 27. Testing Processes And Principles
- Chapter 28. Test Design And Architecture
- Chapter 29. Implementing Automated Tests
- Chapter 30. Enhancing Deployments With Test Automation
Part VII. Deployment
- Chapter 31. Culture Of Releases
- Chapter 32. CI/CD - Deployment Foundation
- Chapter 33. Building Deployment-Ready Applications
Part VIII. Maintenance And Support
- Chapter 34. Maintenance-Free Mindset
- Chapter 35. Maintenance-Aware Mindset
- Appendix A. References
The Leanpub 45-day 100% Happiness Guarantee
Within 45 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
See full terms
Free Updates. DRM Free.
If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).
Most Leanpub books are available in PDF (for computers), EPUB (for phones and tablets) and MOBI (for Kindle). The formats that a book includes are shown at the top right corner of this page.
Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.