In a typical manufacturing company, a supply chain is the chain of companies that you rely on to make your product. For example, a mobile phone manufacturer buys processor chips from a supplier. That supplier needs to buy a part from another manufacturer. And that manufacturer relies on yet another company for the raw metal.
But what is the software supply chain? And how do you keep it secure? We spoke with Kim Lewandowski, co-founder and head of product at Chainguard, to explain the details.
Your software supply chain is more complex than you think
The software supply chain can be complicated. Mainly because it’s difficult to know how far it reaches. Take a simple example: If you use Salesforce to keep track of your customers, you store your customers’ data on Salesforce’s servers. Not a problem, surely? But Salesforce could have a breach. And what about the servers themselves? Those servers might run on Windows. If that has a security bug, hackers have another way in. How about the software that Salesforce uses to host its website? If that is hacked, you have yet another breach.
“When I think of the software supply chain, it’s all the code and all the mechanics and the processes that went into delivering that core piece of software at the end,” Kim explained. “It’s all the bits and pieces that go into making these things.” -On the Dev Interrupted Podcast at 11:28
Keeping the software supply chain secure involves checking who has keys
The important part of keeping your supply chain secure is making sure that you track down what you’re using. And checking that they’re secure and reliable. Every new third party can be a potential problem. If you don’t do your due diligence, you won’t know what risks you’re taking.
As Kim explained, a favorite analogy of hers is thinking about doing construction work on your own home.
“You have a contractor. Well, they need keys. They have subcontractors. You give the keys out to all their subcontractors. Who are they? Where are they from? What materials are they bringing into your house?” -On the Dev Interrupted Podcast at 12:09
The more third party tools you use, the more out of control it can become
It all comes down to accountability. It can easily start spreading rapidly. One third-party tool that you use to create your software might rely on five separate third parties. And you don’t know what code they’ve got hidden under the hood. Your keys are suddenly all over the place.
The only way to keep it under control is to remind yourself to check and to do regular audits of the services you use. Kim believes it’s helpful to think of every new tool as a package coming to your home.
“How is your package getting to your house?” Kim said. “What truck is it riding on and who is driving those trucks?” -On the Dev Interrupted Podcast at 12:44
Get the full conversation
If you’d like to learn more about the software supply chain, and how to make sure that yours is secure, you can listen to the full conversation with Kim over on our podcast.
Starved for top-level software engineering content? Need some good tips on how to manage your team? This article is inspired by Dev Interrupted - the go-to podcast for engineering leaders.
Dev Interrupted features expert guests from around the world to explore strategy and day-to-day topics ranging from dev team metrics to accelerating delivery. With new guests every week from Google to small startups, the Dev Interrupted Podcast is a fresh look at the world of software engineering and engineering management.
Managing the software development process has been likened to herding cats. In other words, you can’t really do it, but you can sure give it the old college try.
It’s no secret that managing the development of a software project is an imprecise science. Here are nine truisms that I’ve learned over the years that have helped me to understand the limitations of our ability to manage the strange world of software development projects.
1. Estimates Are Always Wrong
Whether you estimate something at one hour or one year, your estimate is wrong. That’s just the way it is. They won’t necessarily be extremely wrong — they might only be a little bit off — but they will be wrong.
If you look at a bug report and think, “That will take an hour to fix,” it almost certainly won’t take an hour. It might take 45 minutes, it might take three hours, but the chances of it taking exactly an hour — even give or take a minute or two — are slim. Now, you might say, “about an hour” instead. That’s a better estimate because actual, precise estimates are wrong.
Now for short projects that might take an hour, this isn’t a big deal. But…
2. The Bigger the Project, the Less Accurate Your Estimate Will Be
The bigger the project, the less precise the estimate will be — especially if estimation takes place at the very beginning of the project. As with the hour estimate above, if you estimate a project at a year, it might take nine months or 36 months. In some cases, it might take five years. There is no way to know when the project is starting out.
The bigger the project, the more “unknown unknowns” there are. There are usually more people involved. That is, as a project’s size increases, there are more variables and more things that will happen that you cannot anticipate. All of these things will add time to the project that you can’t plan for at the beginning because by definition you don’t know that they are going to happen.
3. Focus and Concentration Are Our Most Valuable — and Scarcest — Commodities
When building software, the single most valuable thing required to complete a project is the ability of the developers on the team to concentrate in an undistracted manner.
The fewer distractions, the more productive the team will be. It’s really that simple. One of the main responsibilities of a software development manager is to reduce the number and duration of distractions to the team.
Software developers, when left alone, can be quite productive. When they are interrupted — whether for meetings or by people asking questions or anything else — they can lose that productivity very quickly. We all know about “flow” and how hard it is to get into the flow and stay there. That flow time should be valued like bitcoin and protected as such.
4. Hofstadter’s Law Is the Truth
Hofstadter’s Law is stated as follows:
“It always takes longer than you expect, even when you take into account Hofstadter’s Law.” — Wikipedia
This is related to estimates, but it’s important to note the beauty of this aphorism. You can pad your estimates because you think it will help buy you time to get things done. You can add in extra factors, plan for “unknown unknowns,” and increase your estimates to take into account the belief that it will take longer than you think, but in the end, it will still almost always take you longer than you think to get a project done.
5. You Can Only Run in the Red for Very, Very Brief Periods
You can demand the team put in more hours, come in on weekends -- all those “crack the whip” kinds of things -- and you might get some (very) short-term gains out of that.
But if you try to make it the norm — if you try to run your team's engine at the red line of RPMs on a consistent basis — you will burn out the engine. You will see diminishing returns pretty quickly. Employees will leave. People, like race car engines, cannot be overstressed for extended periods of time without breaking down.
6. Brain Time Is More Important Than Butt Time
This one is so important, I wrote a whole blog post about it.
Nothing will decrease productivity more than demanding Butt Time (i.e. that your developers be seen sitting in their chairs for hours on end). You can measure Butt Time and feel like you’ve got a metric that will really show how productive people are being. But you’d be wrong. Demanding Butt Time will demoralize a team that really wants to spend Brain Time.
Brain Time is what really matters. Think about it this way: Let’s say you are a manager and it is most important for you to see your team sitting at their desks “working.” You wander around the office seeing those developers sitting in their chairs, pounding away at their keyboards. All is well with the world.
But then you run across one developer, and they’re just sitting there staring at their screen. That’s it. They’re sitting and staring. For like half an hour. What the heck! They’re not doing a thing!
But of course, they are. They’re thinking. They’re spending Brain Time solving a very difficult problem. Maybe they even get up and wander around the building for a while. In the end, they sit down, type 11 lines of code, and mark a user story complete.
Did they meet your “Butt Time” criteria? No. Did they produce an elegant solution to a very difficult problem? Yes.
Butt Time proves nothing. Brain Time means everything.
7. Hardware Is Cheaper Than Developer Time — Way Cheaper
Developers are expensive. You pay competitive salaries to attract top talent. An hour of their time is not cheap. Despite this, many companies don’t realize the incredible value of an hour of a developer’s time and skimp on hardware for the team.
But come on, computers are expensive! That extra RAM will bust the budget for hardware!
Well, it might bust the budget, but that’s because you’ve got a budget problem.
Look at it this way: Let’s say that you pay a developer $100,000 a year — or around $50 an hour. Let’s say they spend an hour a day waiting for the compiler to do its work. However, you could add some RAM and a faster processor to that developer's machine and cut that time down to 45 minutes a day. You save 15 minutes a day. At 200 days a year, that is 50 hours. At $50 an hour, that is $2,500 saved per developer per year. But what if the incremental cost of the faster machine is $500?
You get the point. If you have 20 developers, getting the faster machine saves you $40,000 for a $10,000 investment. That ought to be a no-brainer.
And that is only for the faster compile times. Everything else they do will be faster as well.
If your budget doesn’t allow for faster machines, then you need to adjust your budget.
8. If You Haven’t Read “PeopleWare”, Then You Aren’t Really a Software Development Manager
As far as I’m concerned, there is but one book that will teach you how to manage software developers: Peopleware by Tom DeMarco and Timothy Lister (be sure to get the third edition…).
This book is excellent, insightful, to the point, clear, and pulls no punches. It is full of wisdom about managing software projects and software developers. It is timeless.
9. Quality Is a Perception — Not a Bug Count
This one is really hard to accept.
Here’s the basic premise: You can have close to zero bugs in your bug tracker and people can still think your software is buggy. You can have a large number of bugs in your bug tracker and people can think your software is as solid as a rock. There’s no correlation between the number of bugs in your tracking system and the perception of the quality of your software.
Now I’m not arguing that you shouldn’t try to reduce your bug count — quite the contrary. But in the end, your software can only be said to be of high quality if your customers perceive it that way — and your bug count won’t necessarily dictate that. Weird, huh?
And while we are on the subject, what does it mean to have a “high” bug count? What is the definition of “high” when your codebase has 100,000 lines of code? 5 million lines of code? Who’s to say?
Bringing a software project in for a safe landing on a short runway is a challenging and difficult proposition under the best of circumstances. Add in the ambiguities and all the things that can go wrong along the way, and it’s a miracle anything gets done. Development managers need to be flexible and take things as they come
The trick is to accept and understand those ambiguities and to work with them — not against them. Accepting these nine truisms will help with that.
Sponsored by LinearB
Want to reduce a lot of that ambiguity? LinearB can closely track what is happening in your software pipeline, enabling more brain time, and automating things that require butt time.
Book a demo today and find out how you can drastically reduce your code delivery times and continuously improve your development process.
If you haven’t already joined the best developer discord out there, WYD?
Look, I know we talk about it a lot but we love our developer discord community. With over 2000 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No salespeople allowed. Join the community >>