Building Bad Software Faster

,

I saw a talk about building software recently with an interesting quote: "if Henry Ford had asked customers what they wanted, they'd have asked for a faster horse." This was with regards to talking to customers, getting feedback, and having this drive your product direction.

It is important to talk to customers, and understand what their needs and issues are, but you have to remember that customers have a very limited experience. They often think about changing, or evolving what they already see in software. They don't think about very different experiences.

True innovation involves feedback from customers, but it also involves a lot of trying. A lot of experiments. And a lot of failure.

That can be hard for many developers. We don't like to fail. I think the same thing can be true of database developers. We are used to writing queries that work and meet some specification. We are used to some success when we build software.

When we build the database foundation on which lots of software is built, we need for our foundation to be solid and work. However, we also need to support experimentation and changes. In some sense, we should learn to model and run experiments in way that allows us to continue them or shut them down. Continuing means evolving the schema in a way that will support growth and scale over time. Shutting things down means getting rid of the schema additions and potentially archiving data.

Moving to DevOps does mean moving faster, but we shouldn't be building worse software. If anything, we should be learning quicker where we've written bad code, designed a poor model, or deployed poorly written code. We ought to then be able to fix it just as quickly.

Rate

Share

Share

Rate