TL;DR It's 2018 & for majority of developers speaking to a business person (/stakeholder /user /sponsor) is still a grand rarity. We explicitly ask for "layers" of intermediaries who can translate business to tech & back. And once it gets to crafting the actual solution we either reduce ourselves to purely subservient automatons ("I do what I'm asked to, so where does this button go?") or follow the other extreme ("Provide written requrements until 10th, then we'll make something out of it & let you know"). We feel too comfortable in "secluded IT enclaves" where we can reduce problems to deal with to purely technical (in 95% meaningless) ones. Solution: BURN THE ENCLAVES.
Do you recognize the two-piece software development "law" quoted in the post's title? No? Lucky you (or very naive). That's the golden rule of (typical) software development workshops who build products for other companies (their clients). Rule that unfortunately frequently expands (even now, in 2018) to companies that build their software internally (via domestic IT), within the bipolar reality they've shaped themselves:
- Them VS Us
- Ignorant VS Knowledgeable
- Those-Who-Don't-Know-What-They-Want VS Those-Who-At-Least-Know-What-They-Can-Do
- Business VS IT
What's the exact meaning of this rule?
As software creator, at the beginning:
- you can promise anything as long as you're either imprecise enough or there's no unequivocal (hardcopied) evidence of your words ...
- ... because initially your goal is to get the endeavor (project, program) rolling
But once you get closer to assumed delivery deadline:
- you deliver what can realistically be delivered (within the timeframe, budget, etc.), according to your judgment & constraints known (/clear) only to you ...
- ... because in the end in 95% of cases client has no other option but accept what you bring in (unless it's not usable at all or there are super-clear legal limitations)
Perimeter is "secured"
This rule is about IT people who are firmly convinced that they know better (so they don't need to probe/ask/clarify).
- "Business" is evil, they always try to sneak something in.
- "Business" is stupid, cause they don't understand how the software is built.
- "Business" moves like in a dark, because they don't know what technology is capable of delivering.
- "Business" is dim, because 150 pages-long specifications we ask from them have always some inconsistencies & mistakes ...
There's just no other option but to isolate brave, smart, skilled tech people from all these halfwits that go under the name of 'users', so they can build their technical masterpieces undisturbed ...
One could think that this way of thinking will without a doubt die a natural death - whole markets jump on "digital" bandwagon, there are more & more success stories of small, focused, fully interdisciplinary teams that have gained unprecendented competitive advantage due to close collaboration of very different specialties on one, single, common goal. Sadly, many (intentionally or not) refuse to understand what's truly necessary to build good software. Various types of consultants preserve this knowledge gap (that's what provides them continuous inflow of new business), so do internal IT executives (to solidify the boundaries of their "princedoms") - "transparency" & "openness" frequently remain meaningless buzzwords that appear in occasional presentations.
IT Departments are so 90s
OK, I think it's the highest time for the punchline.
IMHO med/large organizations which'es core domain (their main source of income) is based on their own software products/services should not have separate IT departments. Or rather, they should have multitude of them - each linked 1:1 (preferrably incorporated into) to the business unit it powers (I didn't use word "support" on purpose).
Just to clarify this way of thinking:
- this applies to business units that do work directly on the core business (auxiliary/supporting domains can rely on generic, external services)
- some "IT competency mgmt" across the unit boundaries is more than welcome (some sort of HR function) -> to set recruitment approach, to provide basis for technical career path, to encourage technical knowledge exchange, etc. -> but it should be absolutely non-decisive in terms of scope, delivery, etc.
- even the "drivers" (architects, engineering managers, etc.) should work for particular business units & contribute directly to business produducts/services that just rely on software
- IT centralisation is highly overrated this days - commoditized cloud services, specific SaaS and/or vast libraries of openly available components do cover for the generic needs that could provide some savings - what software-based companies need to care for now is: agility & inertia in context of change -> it will save much more costs long-term than overzealous standarization
It's the highest time to stop thinking about building software in context of "factories" that collect the work items from the endless (& obscure) queue of company-wide demand. Software development became a universal skill that can be applied to huge variety of problems, in pretty much any team - but to make it fly, it has to be involved directly (& immediately), because solution is NEVER made only of the pieces of code.
