This is the time of the year when a lot of us spend a little
time reviewing how well we did last year and what we plan to do this year. As
you may have noticed, I’m making my plans a little more obvious this year.
Before we get too committed to the planning process we should ask ourselves:
Do we learn from our mistakes?
Because if we don’t, or at least if we don’t try to learn
from our mistakes, then the activity is essentially futile and we would be
better doing something else instead.
I think that the IT industry is particularly bad at this. We
have very little sense of history. We claim to be making progress – but are we?
Here is one person’s attempt to write down an outline of
that history. I can’t say I agree with it entirely. In fact I haven’t really
tested it critically. But do think that it is a worthwhile effort to present
one view of that history.
Why do I think the IT industry is bad at learning from it's mistakes?
Why do I think the IT industry is bad at learning from its
mistakes? Basically, I think this because I frequently get a feeling that “I’ve
seen this before”. Now there is no doubt that a lot of progress has been made.
A lot of that progress is down to “Moore’s Law” which has enabled whole
industries to sprout, bloom and flourish.
The reducing cost of hardware in general and processing
power, storage and communications has enabled things to happen which while they
were conceivable, were hardly practical just a few years ago. This blog and the
thousands like it are an example of that.
But, if you look at various internet forums as I do, you will
find recurring themes which I am going to share with you here and I may pick up
as topics at some time in the future. The thing is that many of these
meta-topics have been running for donkey’s years!
- How do we write “requirements” so they are understood by the people who want the system and also by the people who are going to build the system?
- How do we create things so that people get what they are expecting?
- How do we estimate how long it is going to take us to do (practically anything)?
- How do we manage a project so that it comes in “to specification, on time and on budget”?
- How do we prevent “silly little bugs” creeping into the system?
Maybe you have some ideas for other topics in the same area,
or maybe you have some solutions to some of these conundrums.
No comments:
Post a Comment