Learn how to be a wildly successful small business programmer
Steve McConnell hosted a webinar that I think more people need to see.
We actually know a fair bit about how to create high-functioning, effective software development organizations. The knowledge exists but not enough teams are applying it.
So, if your team is struggling in any way or if you are trying to convince your manager to invest in better practices, this talk is well worth watching.
Despite being all around us, safety-critical software isn’t on the average developer’s radar. But recent failures of safety-critical software systems have brought one of these companies and their software development practices to the attention of the public. I am, of course, referring to Boeing’s two 737 Max crashes, the subsequent grounding of all 737 Max aircraft, and its failed Starliner test flight.
How could such a distinguished company get it so wrong? Weren’t the safety standards and certification process for safety-critical systems supposed to prevent this kind of thing from happening? Where was the FAA when the Max was being certified? These questions raised my curiosity to the point that I decided to discover what this specialized field of software development is all about.
In this post I’m going to share what I learned about safety-critical software development and how a little knowledge of it might be useful to “normal” programmers like you and me.
Our industry is famous for delivering projects late and over budget. Many projects are cancelled outright and many others never deliver anything near the value we promised our customers. And yet, there is a subset of software development organizations that consistently deliver excellent results. And they’ve known how to do it since the 1970s. In this post I’ll tell you their secret.
Stop me if this sounds like you. Somewhere along the way someone put you in charge of something at your job. Maybe you’re coaching a new hire, maybe you’re a technical lead on a small team, or maybe you’re running a whole project. Regardless of what you’re managing, you need to deal with people and that’s not going quite as well as you had hoped because managing programmers is hard. And it can be hard on your sanity.
(As an Amazon Associate I earn from qualifying purchases.)
Maybe you even picked up a book or two about management in the hopes that you’d find something–some trick or skill–to help you manage your people better. I can tell you from experience that most of those books are crap. But there are a couple of exceptions and in this post I want to give you a summary of one of them: The Coaching Habit: Say Less, Ask More & Change the Way You Lead Forever (paid link) by Michael Bungay Stanier.
So, if you’re reading this it means you’re involved in a software project that’s a steaming mess and you want to explore your options. Don’t be embarrassed. This is a safe place; we’ve all googled “rewrite vs refactor” at some point.
The problem is that our profession is long on opinions and short on evidence for what to do with troubled projects. And the opinions we have are all over the map. So, it’s hard to know what you should believe.
In this post, I’m going simplify things for you and help you navigate the rewrite vs refactor debate.
Is it possible that you’ve undervalued or overlooked stories in your backlog that will return thousands of dollars on every hour of your effort? Are you sure you’re working on the most important thing?
If you died in a car accident on your way to work tomorrow would your replacement be able to access your systems and work products? Or would they be locked out of everything and struggle for weeks or months to gain access and move forward? Business continuity planning is something most people associate with CEOs and big companies. However, as the sole software developer in my company for many years I was acutely aware of how screwed my employer would be if I died suddenly.
In this post in going to show you the steps I took to ensure my company wouldn’t be crippled if I died.
In my last post, I introduced you to qualitative cost of delay and CD3. I argued that rational teams should order their backlog for maximum economic benefit and that you can use cost of delay divided by duration (CD3) to do that. Because software developers aren’t accountants, I used the easier to understand qualitative cost of delay and CD3 in my examples. But in this post I’m going to discuss at the advantages of switching to quantitative cost of delay.
I know this stuff isn’t as interesting as reading about the latest advances in AI or your favorite framework. But trust me when I say that learning to order your backlog by quantitative CD3 will help you take your effectiveness to the next level.
Ordering your backlog for maximum economic benefit is a hard problem. The average team is being pulled in several directions at once. New features requests, technical debt, existing defects, non-functional requirements, security, risk mitigation, resource shortages, and more are all competing for your team’s attention. So, how does a rational team decide what to work on? In this post, I’m going to show you how to prioritize your product backlog by CD3, which is cost of delay divided by duration.
Simultaneous feature development is a common but often economically sub-optimal software development practice. In this post, I’m going to look at the financial implications of simultaneous feature development and show you what you can do instead to achieve better outcomes.
© 2024 Small Business Programming
Theme by Anders Noren — Up ↑
