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.
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.
Top comments (8)
It's about time we all got off our tiny planets and explored the vast galaxy together. There are too many things to try and see to allow ourselves to be boxed in by the meaning of todays-favourite-trend-word™.
We should be trying to fulfill goals, not processes.
Good point Ben! I totally agree with you. I just had a similar situation on New Year's Day with one of my good friends (also dev), when we discussed the word: platform. For him, it was something like Facebook, Twitter and so on. And I totally agree with that, these are very good examples for social media platforms. But for me it was also kind of a business model, which means the software is particularly designed to be a platform. So we ended up with 2 point of views and a long discussion.
It is also the same with the word: servers. It really depends on your point of view. As a hardware guy, you mean the host computers (server-racks, server-farms, physical machines), but as a software guy you interpret servers differently. It is software, which runs on a machine and provide something for you. In context of the web, these might be web-severs, like NGINX, etc.
I think what would be really cool, especially for beginners, to have kind of a dictionary, which contains the common words and their definitions and highlight also some misinterpretations and different point of views. Maybe this is something what the DEV.to community could build over time 😉
I'm not sure what the "Agile methodology" is.
The Manifesto for Agile Software Development is a set of four values and twelve principles. It does not prescribe any kind of process.
There are many different kinds of development methodologies that embrace those values and principles. For example, XP.
There are also lightweight management processes, such as Scrum (q.v., The Scrum Guide), that compliment using some sort of agile-based methodology, such as XP.
In my experience, I have never seen Scrum implemented in practice as described by-the-book. At best, maybe a 50/50 blend of Scrum and... umm... Not Scrum; at worst, using Scrum terminology for the parts of a Waterfall heavyweight management process. “In theory, theory and practice are the same. In practice, they are not.”
From my perspective, the practical part of agile software development that makes agile actually agile is Engineering Practices Necessary for Scrum.
All that being said, the greatest factor is not the management process, nor the development methodology... it's the people and having a functional team and using The Joel Test as a quick tally sheet.
I didn't knew Joel test and your conclusion seems good thanks for sharing
I disagree that it's "not a case of semantics". As a philosopher will tell you, you need to define your terms and scope before you start, otherwise all you do is argue semantics. When you define a term, you need to define it in terms of its scope.
I tend to agree here. Some of this is different perspectives, the problems I face day to day to day and try to solve is different from yours. The other part is that we all make assumptions what common terms mean, that is why defining terms so we all are coming from the same point is important.
I think we are all guilty of this.
My blog posts are aimed at small business programmers working alone or with maybe three devs tops. So when I write about documenting your processes and making your passwords available to your boss in the event of your sudden death, what's acceptable in my context is completely different (and possibly dangerous) if you worked at Google or Adobe or something. Yet, I didn't clearly state that assumption in the post. I assume my readers will figure it out from everything else on my blog and my bio but it's certainly not guaranteed.
Interesting...So when we pair with someone should we make it clear what we understand about a particular topic from the start ? Should this be done even before the pairing ? Like should we build a relationship with a co-worker and understand their view point objectively and vice-versa ?