October 6, 2009 at 8:19 am
Dream Weaver (10/5/2009)
How can we create or evolve into an Agile organization (of which IT is a part)? A lot of the Agile signatories are working on this but it's probably the hardest part of the whole Agile proposition. In such an organization there is no need to fear that a quickly-hacked up prototype will end up in production for years--maybe that is exactly what the company needs!
Sure, until the integer row id maxes out and the business-critical tool suddenly fails irretrievably. Or some other hardcoded assumption breaks down.
But you fix that easily and bound ahead to the next challenge because you're Agile, I suppose.
October 6, 2009 at 3:35 pm
I suppose I didn't make my point clear. Sure, if the quick prototype that's added value out there in production for three years suddenly breaks, then with a little down time it can probably be fixed. If downtime is unacceptable or overly expensive, or if a change to the app would set off a ripple of required changes all over the company, then clearly the quick prototype should never have been allowed to become mission critical without evolving into something far more robust, with special care taken to its interfaces with other systems.
The agile organization (not just IT development team, but organization) would be able to tell the difference, get the quick version out early in order to gain a little knowledge and feedback, and either stop because it's good enough or continue until the mission-critical requirements are met.
"Agile development," done well, has a great track record, tending to produce higher-quality, more valuable, and more flexible results in the same or less time as non-agile development. There's empirical evidence to show it. "Agile organization" is much harder and I haven't personally seen a success story, although I think there have been some.
But don't throw out Agile development just because the organization hasn't caught up: who's to say that the non-agile development team would have been less likely to slip that ID field limitation out there?
November 1, 2009 at 4:34 am
That's a great editorial. The gap between IT departments and their users, and the total lack of effective communication, isn't anything new but it does seem to be affecting more and more companies.
Phil doesn't mention that's there's often also a gap and communications barriers between an IT operations department and the IT development department, and that's all part of the same problem.
Sometimes too (more often than I like) there's a similar gap between DBAs and application programmers.
Maybe it is a sympton of overspecialisation - no generalists who can see both sides of the picture?
jcrawf02 (10/1/2009)
I just saw this article in an ACM newsletter, and am now wondering if this would serve to widen the gap or shrink it?
Well, it took them somewhere between 30 and 60 man years (different amounts of effort and even different elapsed times in different reports) to get 7500 lines of verified code. The effort required is probably an exponential function of the amount of code. So if people start insisting on doing this with everything, in the present state of the art, the gap will widen quite dramatically, because there aren't enough people to do the work. Another worry is that few CS degree courses (and, I think, no IT degree courses) impart even the first clue about formal methods to their students.
In a few more years (maybe a few more decades) formal methods will become more efficient, more usable (it has taken about 35 years to get from first steps to where we are today). Maybe we will start using higher-level, less procedural and more declarative languages which allow easier analysis and proofs. But I won't hold my breath - I expect people will still be using shaky low-level languages like C and singing the praises of unblievably bad languages like C++ long after I'm dead.
And there is a real killer: for big systems we first need to prove formally that the specification is actually what we want, ie that there are no bugs in the specification. Proving that the code meets the specification isn't terribly helpful when the specification itself is full of bugs. And of course it isn't possible to achieve a formal proof unless the specification itself is formally analysable.
There have been quite a few attempts at formal specification and an awful lot of words written about them. But almost all of them have gone the way of VDM: they have become hackers' paradises, and largely drifted out of use. The only one I know of that has been used successfuly for fairly large projects (real life industrial projects, not just experiments in the lab) and is still going strong is Z (), but so far as I know it hasn't been used to get complete formal proofs - just to get a lot closer to that than pretty much anything else manages.
So I'm still very sceptical about building a complete formal proof that software works for large pieces of software with non-trivial specifications any time in the near future.
Tom
November 1, 2009 at 10:03 am
There's a gap often between development and operations, but I believe it's often due to a lack of professionalism. I've seen too many development groups that don't do more than the minimum to test and document their work. The attitude has been in some cases that the developers are no longer responsible once they have turned over the application.
The places where development has worked with operations and taken responsibility, the applications usually turn out much better.
Viewing 4 posts - 46 through 48 (of 48 total)
You must be logged in to reply to this topic. Login to reply