TL;DR Too many problems in modern software solutions development are related to chasm between 'thinkers' (analysts, people with business knowledge) & 'doers' (IT specialists, mainly programmers), yet we're so used to it we treat it as something carved in stone. Why not try to apply the same bridging concept that was foundational for coining the term 'DevOps' to mix these two worlds - software crafters with sufficient understanding (& working ability of) domain analysis & technical implementation sounds almost like a mythical silver-bullet.
Barely anything in life is either black or white, we're usually navigating across various shades of gray, but within certain aspects, things tend to lean towards extremities. Take software solutions' crafts(wo)men (yes, I've used this "oddly looking" term for purpose) - vast majority of the ones I've ever met easily falls into one of two buckets:
- coders - hardcore tekkies who live to write code; they think with OO/FP design patterns, are more fluent with programming languages of choice than english (or whatever their mother tongue is), their priorities & life goals are all about Clean Code, cyclometric complexity or %-age of code coverage with tests, etc. Their pecking order is determined by SO rank & GH stars.
- analysts - oriented on the business goals, domain grokers who live to crunch the problem(s), foresee the risks, model the solution & turn everything into something easily comprehensible by "factory" (that actually builds stuff); they live to gain knowledge (by asking smart, pro-active questions), embrace it intimately & turn into $$$.
Needless to say, both groups kinda despise each other: tekkies don't respect people who don't understand code, peeps with business knowledge tend to treat tekkies as unsophisticated (in terms of treatment) manual workers.
And you know, it's ALL really fucked up.
Betrayal
To tell you why, I need to get this a bit more personal. I've started my career as a developer, I've quickly managed to become a leader of a very small team, finished my studies & faced an important question - what next? I've started some interviews with major players in IT delivery (to get better recognition of the job market) just to find out that in common perception software developers are the ones who are told what they have to do. Monkey-type, socially awkward creatures that turn detailed specifications & coffee into cryptic mumbo-jumbo that somehow transforms into working system.
I don't like being told what to do. I lead, not follow. And needless to say, I don't like mechanical roles where someone else is thinking for me (mapping problem domains into context-specific, solution-focused models), I'm not really a "monkey" type.
So I've decided to leave a canonical "software developer" path - for many, many years I had nothing related with "software development" in my job title (analyst -> consultant -> manager -> software manager). And my primary duties were never primarily about building software with my very own hands. I was responsible for Getting Shit Done, through the whole SDLC - no excuses, no talking myself out of anything, full goal orientation, 100% accountability - the final effect was all the mattered.
Interestingly, my employer's "default" ways of doing all of that was very far from what I was taught before. Majority of even the most "technical" people there would not recognize the modern technology passing by, even if it stopped & kick them right in their asses ... They were using the most crude tools, the simplest architectures & they were denying any kind of novelty that would introduce any delivery risk - for them stability, predictability & reliability (of estimations ...) were far more important than any opportunity. Solution had to be simple enough to have it programmed by total randoms, with close-to-zero investment in their training.
But they were compensating this technical primitiveness with non-technical capabilities beyond others' reach:
- ability to dive deep (& quick) into domain details - as far & wide as needed
- relentless attention to functional details, value-orientation, always acting in function of set purpose
- focus on communication skills & direct collaboration with people who know stuff (SMEs)
- delivery process mastery with forced emphasis on effectiveness & end-goal -> function over form
Undercover
How did I find myself within this system (that was so unnatural for me)?
I was cheating, lying, faking, twisting & maneuvering for ~100% of the time, until I didn't have to, anymore. Basicaly, I've quickly learned how powerful their framework of work is and ... how much it can be improved when peppered with solid dose of properly applied technical expertise. And that's what I started doing -> kept learning very extensively in my free time, reaching beyond my core responsibilities, saving the day by surprise rescue with some technical skunkworks, forcing better solutions no-one else thought about (somehow by forcingly over-stepping someone's authority w/o any remorse), bringing out-of-the-box technical thinking to help the project.
For some time this was unwelcome, openly questioned & my future career was hanging by a thread, but ... quickly it became more than obvious that the clients liked what I was bringing to the table, so I recognized as "commercially viable". And so it went.
Shortly speaking - I've never left developer's path, I've never stopped learning, my passion for tech seems to burn more & more, but ... tech resides in "solution space", so it should always come second - it's the "problem space" that needs some love first: business domain crunching, analysis, problem decomposition, abstract thinking, process mining, systems' theory in practice, ...
Mixing these two worlds is ... like a super-power.
The advantage you have over people solely focused on either the 1st or the 2nd alone is hard to believe - their thinking is shallow & always boxed with invisible walls, even their perception on the targets is skewed by localiness of their perspective, they are not able to propose optimal solutions as they either don't know the palette of tools (analysts) or know the goal only from the chinese whispers game (devs) ...
DevLyst style
If you're a hardcore dev, you may be thinking that I'm clearly being delirious here:
Isn't dev's job about learning (& mastering) programming languages, frameworks, platforms, whole ecosystem to write the code that will make others' dreams come true? Isn't all of that much enough, so we have to think about "the soft stuff" as well?
Frankly, learning new technical stuff is great - as a cradle for new ideas, way to practice & sharpen your skills, extending your arsenal, etc. But:
- for every tech there's a certain borderline beyond which our further learning (of purely technical stuff) isn't really making us able to build significantly better solutions (or make us more effective in any other way) -> this is area of sheer "engineer's selfishness & futility"
- it may not be that obvious at the first glance, but ... this is the way we're fooling ourselves; in fact - work for majority of developers is just ... boring (new form, new screen, new service, new routine, ...) & we're compensating this truth (+ avoid early burn-out) but instinctivily (engineering instinct) looking for fun stuff - distracting us with novelty, so we forget that we're doing monkey work (yes, again: doing poor tech w/o context is in at least 90% a monkey work)
So, you can live within this trap or try to extend your perception. This is exactly what has happened when the term "DevOps" was coined - IT world has learned the tremendous benefits of embracing the foundations of two interconnected worlds: Dev & Operations. Not Dev & Ops in separation, but together.
The mixed profile I keep referring to in this blog post may have been called DevLyst (DevAnal for some reason doesn't sound that appealing ...). A bridge between pure technology & conceptual crafting of the solution using non-technical abstractions. A role model of DevLyst would ...
- ... prolly not know all the syntax & idiomatic usage patterns of all web frameworks available on her/his platform of choice; working proficiency in just 1 is clearly enough
- ... not spend hours on discussing expected advantages of various concurrency models - because seriously, if you're not working on infrastructure solutions' internals, do you really have to care? knowing about providing thread safety & basic concurrency in one, most common model is just about right
- ... understand all the key basic principles of software engineering (like SOLID, DRY, KISS or YAGNI), BUT will remain unconditionally pragmatic about tech zealotry, arch "purity" & code aesthetics
- ... mine the domain knowledge out & extract only the parts which are relevant in current context; next turn them into conceptual, structured model with clear boundaries & responsibilities
- ... understand the value chain - what are the users' key metrics, goals, motivations & concerns; where's money / economic gain in all of that; what do we actually want to achieve, what is the actual problem we'd like to deal with?
- ... distinguish between problem & solution (the easy part), but also between problem, it's root cause & other problem's side effects; will tell whether something is correlated or just a subject of accidential (?) causality
How does it sound to you? Ain't it the essence of what's crucial to build a really good solution?
I think that the concept of DevLyst was somewhere there between the lines of original Agile Manifesto, but got lost on the way to the mainstream. IMHO it's the highest time to resurrect it & recognize it specifically.
For the sake of this industry's sanity, it probably should be The Next Big Thing, the next catchy buzzword ;P, the new 'black' of modern IT 'fashion'.
