Vukoje's blog about software development

Riding Technology Wave

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. 



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.

WPF - 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.

Linq 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.

What to code next?

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. If you choose simplest possible task, you will be able to:

  • implement, test and check in your code easily and quickly
  • 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.