I have had the fortune of learning a lot about development processes and how people approach work. It is always amazing to understand what excites people about work and how they see their role in creating our products. I find great pride in helping people evolve their practices to improve how products come together. Let's explore some observations I have made about what drive people to optimize, and some ideas on how to move to a different way of thinking. What drives optimization? I have noticed a typical driver in how many groups and companies define their development practices. These practices start by working to prevent pains the team has encountered in the past. We build our documentation, processes, and automation around avoiding things that have happened to us before.  “This happened once, three years ago, and in response, we implemented a rule to prevent it from happening again.”  I will share a scenario from my experience.  One of the teams I work closely w...

Some of my youth was spent around farms and ranches, which has left me with interesting perspectives. I could talk/write about these perspectives for a while.  I will focus on one area in this post: reusing old tools to build new ones. Not Developed Here Many software engineers are keen to borrow others' ideas or snippets of code. They are often on board with using an entire library or program that does everything they need. Getting them to use something they didn't create can often be challenging , as it may not directly meet their needs. Or sometimes, they think they can build a better mouse trap so every other one out there won't suffice. We hear things like, "That's not how it should be done.” “What they did doesn't make sense,” and “I can build what we need faster than integrating that system." These are all forms of saying, I didn't make this, and I know I can do a better job, so I won't use it.  I've personally done this many times. It’s...

We usually lean toward terms and methods from other engineering disciplines in software development.  In some ways, this is good, and in others, it isn't.  All engineering disciplines have a strong history of learning from the past and improving on what was done before.  However, there is one aspect where I do not think software development should follow others, and I'm sure many know it well, the construction analogy. The Construction Analogy " We've got to start with a solid foundation and work from there. "  Software development strategy is very frequently related to buildings and construction.  We tend to describe software as a single building with many rooms and interconnected hallways.  When using this analogy, of course, you need a strong foundation.  More importantly, you need a clearly defined plan for everything about the building before you start. It isn't possible to build the proper foundation without knowing everything about how the...