-
-
This week I have attended
Microsoft one day conference DevDays 2009 committed to fresh and soon to come
Microsoft development technologies. Excitement as one geek can be, I still was
annoyed by new technology rush, so I wanted to share some of my taught on that
subject.
Term explosion
When ever I hear about new
things I find my self in mental process of translating them in set of terms
that I understand. This probably is related to lack of IQ but it is mainly due
to term explosion. Every new thing that comes out has to have some cool name
although problem is widely known and defined few decades ago. Please, don’t do
this.
Technology and problems
Technology is here to solve problems, so to use it you first need to have a
problem for solving. If you don't have problems, new technology will bring them
to you. New technology needs to be learned and the God knows what errors it
has. Yes, I still have urge to use newest, fanciest tool, but can I justify it
to my manager? Best thing to do when you get existed about the new stuff is to
ask what are the technology faults, and rest assure it does have them.
Following are some of the question:
- Will it take too much time to learn
it?
- Will other developers except it and
learn it good enough?
- Are enough resources available?
- Are there any major issues?
- Will the product be supported over
next few years?
- What about performance?
- What are software and hardware
requirements for running it?
- Is the software mature and fast enough?
I will quote Facts
and Fallacies of Software Engineering:
-
Hype (about tools and technology)
is a plague on the house of software.
-
New tools and techniques cause an
initial loss of productivity / quality.
- COBOL is a very bad language, but all the others are so much worse.
(Read rest of the post on my blog...)
-
-
When you want to do something, next question always comes
up “What should we do next?” The answer will differ if you are making
decision what module to develop in next few months, or you are wondering what
functionality to code next.
Choosing next module
When you pick a development task for a longer period, always
pick the hardest one. This approach is also called “Swallow the biggest frog first”. This means that if you
will be developing some software in period of one year, in first quarter you
should tackle all biggest risks and most difficult implementations. These hard
problems must be solved before project is completed and if you delay them:
-
they
will only become harder because
already implemented components introduced higher complexity
- you
will not have sufficient time to
solve them because you already burned big amount of time solving less important
issues
-
it is
more likely that important feedback will come too late when too
much time and money is spent
This approach will lead to early pain in
project, where you have large problems right on project start. You should
cherish early pain because alternative is slow and painful project death.
Choosing next functionality
When you are choosing next feature the code, choose the
smallest/simplest one that will work.(READ MORE)