November 13th, 2024, posted in for_founders
by Adelina
Software development is a complex field. One minute, you think you understand how it works. The next, another technology pops up. Thus, At UPDIVISION, we started an initiative of building a library of books and courses that will help each team member grow.
In my process of adapting to the IT field as a project manager, I picked up Working with Coders: A Guide to Software Development for the perplexed Non-Techie by Patrick Gleeson. Divided into 10 chapters, Gleeson’s book explains not only the process of software development, but also many types of challenges it implies and how to tackle them. Personally, I was looking for good resources that could help me understand how the software development process works and how to support it effectively. Or, to put it simply, I wanted to stop asking my developers, “Wait, what does that mean?” every other hour.
Today, I am glad to share with you my takeaways and a short summary for each chapter of this book. Overall, I was kept entertained until the very last page with Gleeson’s sense of humor and personal anecdotes. Lots of the tech-oriented points he made throughout the book were supported by his own real-life stories, which made it all easier to understand for newbies like me.
The book is addressed to:
- Project Managers
- CEOs
- Clients
Chapter 1: Introduction
The book is not about how to code. Rather, it's addressed to people who don't, but greatly depend on coders developing software for them. IT project managers, CEOs, clients - all the actors of the Software Development Life Cycle that have limited technical knowledge, but are exposed to interactions with technical people. This book is also not an attack on techies. It's purpose is rather to demonstrate the complexities of software development and how to work around them. Moreover, it gives a lot of insight on how developers work and how to communicate with them.
Chapter 2: Why Writing Software is Nothing Like Building a House
As the title suggests, this chapter explores why the classical approach of building something (“what to do, how to do it, and actually do it”) does not quite apply to software development. As Gleeson himself says, “Software projects go wrong. Software projects go wrong in an entire cornucopia of excitingly varied ways”. In this chapter, the author explains the three main challenges faced by a development team while building software:
The Imagination Problem - the customer never knows exactly what he wants, thus developers have unclear objectives and specifications.
The Estimation Problem - as “there is nothing so optimistic and unreliable as a developer’s estimate”, developers fail to take into account the uninteresting parts of the job as well as the unknown ones, such as time spent testing, deploying, or fixing bugs. This leads to unreliable estimates that can delay projects way past their deadlines.
The Arithmetic Problem - two completely unrelated tasks are completed by two developers twice as fast. But when programming tasks are somehow related to each other, the gain of using more people starts to decrease, unless they communicate really well. A great way to explain this problem is: "adding manpower to a late software project makes it later"
Chapter 3: Agile: A better, but still not perfect, approach to project management
The purpose of Agile is to deal with and smoothen the impact of the inevitable difficulties of the software development process. Difficulties which, as we`ve seen, are usually caused by the unknowns in specifications and estimations. By embracing incremental development and dividing the project into smaller deliverable milestones, software projects are de-risked.
How this works is the development process is divided into “sprints”. These sprints contain a series of code tasks to be completed in a week or more. All the sprint components are taken from a backlog, a list of all the tasks, and prioritized. Meetings are held before and after each sprint takes place, to clarify each task and to check what’s been done, respectively.
Even though the incremental development approach leads to more meetings and potentially code re-writing, most of the time it is an acceptable trade-off between succeeding inefficiently and rushing headlong into failure.
Chapter 4: What do they do all day?
This chapter takes a closer look at software development itself and the processes it involves. The software development process is composed of several big steps:
- What to build - before a coder can build anything they need to have enough details about what they’re building. This will help them set everything up easier, as they’ll know exactly what they need. Otherwise, it’s a slippery slope of confusion.
- UX details matter - if you don't want to end up with a piece of code that fulfills the technical requirements, but is virtually unusable - think about the user experience (flows, buttons, screens, etc). This can be integrated into functional specs - guidelines on how an app should behave. Specifically, what users can do and what happens when they do those things.
- User Stories - functionalities are built to satisfy user wants and needs. So, in order to deliver good software, one should start by describing what the user wants to accomplish in any given situation. These start out looking simple, but each story will have its own requirements that need to be fulfilled.
- Code - Here, Gleeson presents the main technical aspects of coding, starting from the very basis - that is, binary. He explains how code written by a developer is translated into binary, which is how computers understand and process the code you give them. Many developers use OOP to solve the abstraction problem and to make code more human-friendly.
- Deployment - as a rule of thumb, the larger the release, the harder it is to get it up and running.
Chapter 5: The big green check mark
Since software is produced in most cases by a team or even multiple teams, there are lots of ways in which the production could be considered unsatisfactory. Trying to hire the best people to implement the software is not a good long-term solution to avoid this problem. The smart approach is to put in place processes to ensure quality. This chapter explores the processes by which software can be assessed and quantified, with the emphasis on the main ways in which a piece of software can be tested. The main questions to keep in mind when testing software are:
- Does it do what it says it does?
- Does it do what it doesn't say it does?
- Does it do what it said it did?
But, the author warns us that assessing the quality of code takes time and will slow the delivery. Therefore, sometimes it is more important to take the quick-and-dirty approach: get things done and worry about the consequences later. This points to technical debt, or, as the author calls it, a “concealed flaw in the porcelain jug’. However, the best way to avoid it is time, and software development is always in a crunch.
Chapter 6: Taking the "arg" out of Jargon
Even though, at this point in the book, I’m armed with a lot of information, it is still very likely that if I asked developers what they are working on today, and told them not to translate it into non-tech language, I will almost certainly feel confused. In this chapter, the author talks about the most common topics and tries to explain some basic terms and concepts that are likely to come up in the average software project. The four areas explored are the Internet, Data, Security, and Coding. We hear about terms such as DNS, IP, HTML, JavaScript, databases, encryption, SQL, SDK, and many more.
Chapter 7: So you need to hire a coder
Starting from this chapter, the author takes a closer look at software developers, rather than the process. The author presents the readers with different aspects of how coders think, and what you should pay attention to when working with them. Specifically, the author talks about the hiring process, the fact that technical evaluation is tricky and there are no perfect solutions. When hiring a developer, we should be careful where to set the bar by trying to answer this question: Do I need someone fast, or do I need someone fantastic? If you're not pressed by time, keep saying no until you find someone who leaves you in no doubt at all.
Chapter 8: Programer preoccupations
For someone who manages one or more developers, it is important to understand how they work and how they think. As a result, this will help you make decisions that will make their lives easier, respond more intelligently to their needs and concerns, and avoid getting in their way.
The author explores multiple concepts. For instance, developers have an aversion towards particular tools and technologies. On the other hand, he also mentions "beauty in code" - which is nothing more than a well structured codebase, without unnecessary repetition and divided into smaller chunks of code. Software development can shape how a person thinks and it can lead to interesting attitudes towards the development process, including what a beautiful code looks like. Understanding these attitudes can help people in charge better deal with problems when they arise.
Gleeson also describes several tools often used by developers. Among these tools are forums, or platforms such as StackOverflow, where they will often go to find solutions to their coding problems, or to help others. Here, the author talks about how important it is that developers have access to the Internet, and that it’s not limited in any way.
He also talks about the Hype Cycle: the “life evolution” of new technologies, which at first are risky to use, despite the excitement they produce. After the initial excitement, the first major issues are fixed and it slowly grows into a technology lots of people want to try. Finally, the technology reaches its last stages and it’s talked about less. Gleeson highlights the importance of keeping an eye on forums, to be sure the technology has a strong community around it.
Chapter 9: Keeping coders happy
Happy coders code faster. In this chapter, the author argues that it is important to keep the developers happy. Even though you can’t make all the developers happy, there are plenty of things a manager can do to minimize unpleasantness. One of the "tools" mentioned is the so-called "Joel Test", which is a set of criteria for what makes a good development team put together by Joel Spolsky. This test is made of 12 questions that assess the processes and practices of the team as well as their working conditions, each of which can be answered with "yes" or "no".
Some of the questions are expensive when trying to answer them with "yes", thus it is up to the person in charge to weigh up the benefits of having happy coders against those costs. Specifically, it’s essential that your developers have a quiet space and powerful computers, both of which are not cheap. It’s also important to let them work flexible hours and not pressure them too much.
Chapter 10: When it all goes wrong
In this chapter, the author explores the 3 very unpleasant situations that are very likely to occur in any given project:
- When your team hate each other
- When you're horribly behind schedule
- When your product just isn't very good
Even though these situations happen quite often and when they happen there are no perfect solutions to them, there certainly are some factors that can be changed. Compromises can be made, so that the damage of these events is minimized. With personal anecdotes, Gleeson shows some ways he’s tackled these problems in the past, which gave me lots of good insight.
As mentioned at the beginning, this book is not about how to code. Rather, it's addressed to the people who don't, but greatly depend on coders developing software for them. It looks at different aspects of the software development life cycle, by bringing up the issues one may encounter as well as possible solutions to reduce the damage. One thing that the author emphasizes during the entire book is that there is no perfect solution to any challenge when building software. Overall, Gleeson’s book gave me a new perspective on software development, and will hopefully help me make the best decisions for my team.
