This post originated from an RSS feed registered with Java Buzz
by Michael Cote.
Original Post: Big Bangs Can Cause Big Problems
Feed Title: Cote's Weblog: Coding, Austin, etc.
Feed URL: https://cote.io/feed/
Feed Description: Using Java to get to the ideal state.
Lo for me, 7 weeks on the job, to talk as authorativly as
Steve and
James about "Da Biz," but <a href="Lo for me, 7 weeks on the job, to talk as authorativly as Steve and James about "Da Biz," but that quote caught my eye.">this quote caught my eye:
The analysts are looking for the same thing that IT shops and vendors are looking for: The next big thing (tm).
But, on the other hand, as many of you have pointed out, being so new I have the benefit of "fresh eyes." Betting on big-bets in analysis to the exclusion of paying attention to all the small bets out there seems like a bum-approach. The big-bets are fine, but it's better to discover one than to try to create one: emergence vs. planned.
Small and Big
That also raises an interesting comment that a lot of people I've been meeting have said about
RedMonk. And, pardon the navel-gazing and ego-pumping here (skip the next section if it makes you want to puke ;>).
It's been fun meeting people who know RedMonk and hearing their perspective on them: they're always quite open with what they think of us (as we are with them). They often raise an interesting dichotomy: on the one hand, we tend to be very future looking and "out there" (in a good way ;>) in our thinking, but on the other hand, we're very focused on the day-to-day, pragmatic operation concerns in the industry. For example, we can talk about
astronaut architecture, pie-in-the-sky dreams and, then minutes later, bring it down to
discussions that could be applied today, right now to make things better. "Actionable," they call that last one.
We've got one foot in the muck, as it were, and another in utopia.
I raise that point, because I think it illustrates how we manage to keep our eyes on much more than the Big Bang, and the benefits that brings. OK, self-ego fueling off.
Rapid Feedback Loops vs. The Big Bang
Which brings us to one of my favorite topics, Agile Software Development. Namely, the idea of "rapid feedback loops." The idea is that you get feedback on your progress as you're working on the software. This avoids big bang failure where you work for months on end, ending up with software that is no longer relevant or does exactly what people thought they wanted, but it turns out they didn't want it.
The principal works all the way from unit testing up to entire software suites. There is a question of how long the first feedback loop takes to get to, but getting running software in front of a group of people sooner, rather than later improves the end product.
Several of the people I've been talking with recently about WS-* based SOA have been rubbing up against that notion: if we don't have running software to help drive SOA discussions, are we in danger of falling into a complexity quagmire once we finally deliver?
The longer you wait to deliver -- software, an idea, or any "created" thing -- the higher the risk of failure and the more costly the failure. That's the danger of straw-man waterfall. The positive of waterfall (which is too often snarked-off by Agile thinkers) is that it
might work, and then you can bank on that planning.
In the Future, We'll Always be On Time!
Which brings us to another great intersection of long feedback loops and group-think:
What that leads to isn't corruption, but herd behavior. Without consciously working at it, IT managers and analysts reinforce their own preconceived notions, and are prone to jumping on bandwagons.
This is part of why, when you ask all the teams "how are we doing? Are we going to make the date?", that they answer "yes!" and then you end up delivering 2 years late (or delivering on time, but delivering crap).
No Ending
There is no more gigantic point than the above: sort of my broken record declaration of my membership in the KISS-crowd. There are few better process-tools that you can use to drive a KISS approach -- whether delivering software, analysis, or almost anything else -- than delivering early and often, and it certainly helps you avoid The Big Bang of Failure. I'm not suggesting that you throw out everything else -- didn't you see me give credit to waterfall where credit was due? -- but there is a certain trepidation that the hi-tech industry all has to "running with it" to see if it's a good idea or not...kind of like this ending ;>
It does go both ways though: you can't attack people for taking that approach when they fail. We see that all too often when knee-jerk zealots in any camp poke fun at what vendors (incorporated and otherwise) do. Indeed, that's another point to be made: the audience has to be accepting of delivering early and delivering often. Otherwise, it's probably best to ride out the blast waves of Big Bangs.
Previous Topic
