Correct Answers Are Few and Far Between in Software Development
Published: 2018-01-25 17:52:42

---
title: Correct Answers Are Few and Far Between in Software Development
published: true
description: It's not that we disagree, we weren't even answering the same question.
tags: 
cover_image: https://photojournal.jpl.nasa.gov/jpeg/PIA13994.jpg
---

I recall a discussion I had with an product manager at Oracle. We were talking about how they were trying to get into a more "agile" workflow. I was happy to chat about my perspectives. But I quickly realized that we were coming at this discussion like we were from different planets. His idea of "less process" seemed like mountains of hoops and paperwork and specs to me. I couldn't even begin to give advice because some of these hurdles are not even on my radar due to the nature of the work I have done.

Agile methodology has a specific connotation, but "agile" is also a descriptive word. Those language hiccups are always tough to navigate in our space. However, conflict here doesn't come from semantics here, it comes from world views. Different experiences lead to radically different interpretations for what "fast" means, what "safe" means, what "secure" means, and on and on and on.

On Tuesday the [#DevDiscuss](https://twitter.com/hashtag/devdiscuss) Twitter chat was on the topic of "Feature Creep". As the conversation started, I felt like this concept meant entirely different things to different people. And even if we agreed on a definition, solutions were all over the place. If you work for clients as a project-based consultant, you have one perspective. If you work for Silicon Valley giant, you'll have an entirely different way of describing your concerns. Same with startups, government contracting, teaching, and on and on and on.

By the way, the different perspectives and solutions really made for a great chat.

{% twitter 955988813746135041 %}

{% twitter 953449065156620288 %}

{% twitter 953451173478092800 %}

{% twitter 955995180787642368 %}

I remember hearing the term "cloud native" for the first time at a software conference. I heard it not just in talk titles or marketing material, but as a word used regularly in casual conversation. I'm not ignorant the history of on-premise computing or good reasons people continue to manage their own servers, but I cloud native absolutely _feels_ default to me. So the conversations I had with developers who worked for companies like Target were fascinating in how they looked at _the cloud_ and what problems you solve with it compared to how I saw things. They were fine with a certain class of problem that would be a non-starter for me. And I was fine with problems that wouldn't fly in their world—their planet.

For some, working with one million things (database records, processes, whatever) might seem daunting. Given a slightly different set of experiences, one million might seem like a hilariously small number.

For me, working with a million things (database records, processes, whatever) might seem daunting. You might chuckle at that number. My elegant solution might make you puke. You can't imagine coding without a type system, for me I can't imagine waiting for compilation. For you, great documentation is everything. For me the code should always be self-documentation. You might practice strict TDD, I could go either way. And if we both say we love TDD, we might sit down to pair and realize we have _radically_ different definitions of what that means.

This is not a question of experienced vs inexperienced. Nor is it an issue with entirely different domains. It's a reality of the branching factor in our space. Divergence happens at every turn. When this happens enough, we come to settle in on our separate planets. This can lead to painful miscommunications or disagreements. It's also how we grow and learn from one another. It is always fascinating to find out that someone had a radically different world view on the exact same software development concept. It's not that we disagree, we weren't even answering the same question.