I keep forgetting how diverse & "flavor-rich" is our industry (software development). Not just in terms of tools, but also outlooks, opinions & overall openness to change. Within last two weeks I was exposed to software engineers ...
- ... complaining on Microsoft going to fast with their web stack - they didn't manage to fully embrace MVC yet (!) & there's the vNext thing around the corner ...
- ... claiming openly that 2016 is gonna be the year of COBOL renaissance (!!) & big mainframe comeback (that was for real & there was even a professionally formatted article published ...)
- ... stating that generalists (devs who don't focus on 1 particular, narrow tech / platform / language) are useful, because there has to be someone to communicate through (!!!) with business people
"I'm a developer, I develop"
I'll put first two bullets aside as two nice ice-breaker jokes, but ... the last one deserves being addressed, as I keep hearing it every now and then and it is by no means a joke - many developers still think that:
- it's fine & valid to avoid learning anything about domain (because they are programmers, not merchants, doctors or bankers)
- communication skills are nice-to-have in the roles they play (because they are employed to write code somebody asks them for)
It's so 90s, isn't it? I know quite a few companies that still operate like this (due to different reasons), but even if you (& your employer) do so, it's good to realize that this is most likely still not the optimal & most desired model.
The usual excuse
We tend to blame our "innate" (lack of) social skills:
#1: "Introvert, taciturn, just leave him alone - he writes great code when no-one bothers him."
#2: "If we force her to talk to business people, she either offends someone or rage-quits tomorrow, first thing in the morning."
#3: "He's a geek & the majority of geeks are introverts. That can't be changed & you have to accept that if you want to work in software development."
I'll say - let him/her leave. Seriously.
This game is not about implementing detailed design specifications with 5 sign-offs (aka "shit in, shit out"). This game is about direct co-operation of business, users, developers & any other kind of stakeholders you can imagine. There's no space for playing "chinese whispers" through proxies & mediators anymore.
It's a team game, not a solitaire.
Successful development is not about using the latest version of framework with the most sexy pattern that has got the most retweets last month - it's about efficient materializing great business ideas into:
- firstly, adequate domain models - that both reflect the vision & are technically implementable (coherent, unequivocal, bounded, deterministic, etc.)
- secondly, software products / services - that represent the domain model in the physical world
The more people are in between (business need & software product), the worse the effect becomes. That's why the most vital aspect of DDD (Domain Driven Design) is not its terminology or notation, it's direct co-operation between technical & business people who create the domain model (an intermediate product) together, using shared (binding both sides), ubiquitous language (terminology). How can you do that if you're afraid of speaking with your client/user? How can you be sure you really add value if you don't even understand what (& what for) you're supposed to build?
The role of Business Analyst
Another excuse is the role of Business Analyst (I'll use the acronym BA from now one, but the terminology may vary - sometimes they are being called just Analysts, Solution Designers, etc.). Aren't those supposed to cover the bridging? Or maybe my point is that they are not necessary & teams should get rid of people who play these roles?
BAs are needed. But not as proxies, but someone who works in parallel with developers. Developers care for the technical part of changing software products (technical design, implementation, automated testing, deployment procedures, etc.), BAs cover all other aspects, among others:
- design the change in organization (how do processes / people duties / responsibilities / etc. change) to accommodate change in software products
- prepare the change in organization (knowledge transfer, transition itself) to make sure business goes as usual & nothing gets disrupted
- cover broader, service perspective - where software products are only service providers - the components of which processes are built
BAs are supposed to work hand-in-hand with developers to make sure software doesn't just reflect excellent, but unrealistic (impossible to put into practice) idea - it has to be feasible to actually deploy into actual, on-going business processes within organization. Without casualties, but rather with a measurable, positive effect :)
And about you ...
So what about legions of people who've never spoken to a business person, communicate mainly via HipChat / JIRA tickets & feel confident only within Eclipse / Visual Studio? What about you?
Not much, no-one will force you to change if you resist. But there are few facts that are hard to argue with:
- 99% of us CAN improve their social / communication skills if we only want to - this is not something you have to be born with, in vast majority of cases this can be worked out just like any other type of skill
- "limited interface" developers are just as stubborn relics of the past era as people who keep using Windows 98 - they are still quite fine on their own, doing their own (well known over the years) shit, but problems appears once they have to interact with anyone else - they find out they are lagging behind the rest of the world. And they tend to blame the world.
If you haven't made a New Year's resolution yet, why not make it a soft skills-related one?
Pic: © ptnphotof - Fotolia.com
