Posts categorized as: software-engineering

Waste elimination is critical to delivering value through software. In the late 1940s, Toyota had a problem. Manufacturing was expensive, so prices were high. But the typical car buyer in Japan was light on cash. Reducing the cost of manufacturing was the only way to sell cars. Mass production could have solved the problem, but Japan’s economy wasn’t large enough to create demand for thousands of cars. Toyota had to find another way, and they turned to Taiichi Ohno.

As much as I loved my Computer Science curriculum at Ole Miss, it taught me nothing about being an effective software engineer. When I was in school, Computer Science programs were optimized for producing grad students. Grad students need to excel at research and publishing. Not shipping software. My career experience has provided no evidence anything has changed. To be an effective software engineer, you must learn on the job.

When I got started, I didn’t know a damn thing about software engineering. It was 2001. I’d just earned my Computer Science degree and was starting my first job. I’d taken the one software engineering course my university offered. I thought I was ready for any coding task they could throw at me. I couldn’t have been more wrong. If you do the math, you can tell I’m 20 years into my career.

The best thing you can do for your software engineering ecosystem is to add constraints. What do I mean by constraints? Anything that limits the degrees of freedom you have when building a software system. You might call them: limitations restrictions standards contracts controls Regardless of what you call them, constraints will make your team better. Here are five reasons why: #1: Constraints limit the number of decisions you have to make.

Our industry is possessed by a deadly cycle. As we build software systems, we always run into complexity and problems. We see happier teams using a shiny new technology, and we run away to its greener pastures. Eventually, we discover the same complexity and problems that made us run away in the first place. I’ve seen this cycle multiple times. From Java, EJBs, and Spring to Ruby and Rails From Ruby and Rails to Node.

If you’ve been a software engineer for very long, you’ve probably worked on a codebase that’s seen better days. It’s not clear where the next feature should be added. Some components do too much, and some components do too little. Every change you make seems to break something else. Writing software has transformed from delight to drudgery. Your task list has become a toil list. But it doesn’t have to be this way.

Do you really understand single points of failure? A Single Point of Failure (SPOF) will cause an entire system to fail, even if it’s the only broken component. The Power of Multiplying By Zero is a mental model we can use to better understand SPOFs. Consider these two expressions: 865309 x 42 x 1984 x 221 x 0 865309 + 42 + 1984 + 221 + 0 Assuming you have beyond a third-grade education (or your country’s equivalent), the second expression may take you a moment, but the first expression should evaluate itself.

Builders run into problems. If there’s anything a product team should be good at, it’s solving them! But most of us rarely spend time sharpening our problem-solving saw. Enter the concept of mental models. Models give us abstractions of how one or more things actually work. They help us understand the world. George MacGill provides this analogy: If your consciousness is the operating system, mental models are like apps, which you can use to help make decisions in whatever situations you find yourself in.

Your technology organization cannot afford unlimited innovation. Dan McKinley coined the term innovation token to model this concept. Every organization gets a fixed supply of approximately three innovation tokens, and it can spend them on anything. As your organization grows in maturity, you might earn a few more tokens. But for the foreseeable future, the supply is fixed. How does this work in practice? Well, let’s start spending tokens: Let’s choose Elixr for our backend services.

In 2008, I believed the only way to save a critical software system was to rewrite it from scratch. I had just been promoted to engineering manager of my team, and that system was our biggest project. And it was in trouble. I knew we had made a lot of mistakes along the way. Now that I was “in charge,” I was going to fix everything. That rewrite almost failed, and I nearly got myself fired.