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 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.
opy & paste@beeg_smithFor anyone wondering “wtf is feature creep?”
Day 1: Your boss wants you to build a a new payment form
Day 2: with a progress tracker
Day 10: that also notifies the user when their favorite song is on the radio.
#DevDiscuss twitter.com/thepracticalde…02:21 AM - 24 Jan 2018The Practical Dev @thepracticaldevTime for the #DevDiscuss Twitter chat. Tonight's topic is FEATURE CREEP (it can happen to you) https://t.co/YcQX53Ikxs
Kelly Vaughn@kvllyThe most rewarding job change you can make is transitioning to working full-time for yourself. It's not for everyone, but so much satisfaction and pride comes from knowing the money you bring in each month is thanks to your own hard work. #DevDiscuss02:09 AM - 17 Jan 2018
Aga Zaboklicka@pauxdsantamaria @ThePracticalDev Feature creep is a legacy of waterfall project management when companies didn't have ongoing, iterative deployment with constant feedback so they tend to ask for everything they could during the specification phase #devdiscuss02:46 AM - 24 Jan 2018
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.