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
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
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
- 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.
Workflow Foundation - When I first saw it I
went nuts. I taught it is the next big thing. Today I can't imagine any use of
this technology in my everyday work. I guess that some software houses working
on software with extremely big and complex business processes that need to be
configured at runtime by business users can find good usage for it.
- No tools, no GUI controls, slow. Will be standard in future, but for now
I don't want tell customer to buy better PC so he can run my address book.
to Sql - This technology is dead, so I don't plan to use something depreciated by
manufacturer. I have bean there with UIP
and it is not a happy place.
Entity Framework - I am most exited about
this one, but it is simply not mature and stable enough and there are very
little resources. On PDC presentation it was clear that they still
aren’t sure what will next version look like.
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:
will only become harder because
already implemented components introduced higher complexity
will not have sufficient time to
solve them because you already burned big amount of time solving less important
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. If you choose simplest possible task,
you will be able to:
test and check in your code easily
- you will reduce chances for making a mistake because
work is small and simple
- you will
be less stressed because
there will be less things that you have to hold in your head
- undo all changes and start from
beginning if you get lost or insecure
I have stolen this principle from TDD and Refactoring principles.