At the MVP Summit I got more than just new technology and roadmaps, many people have the philosophy of building software. I now it’s being a while since the 2009 MVP Summit, I wanted to practice the philosophy before posting it and saying that is the best thing since slice bread. Just to make sure to give credit where credit is due, this is was my philosophy, I “borrowed” it from the right people:
- Scenario focused
- Business customers drive scenarios.
- Scenarios drive the technology.
- Technology does not drive the scenarios.
- Scenarios should be end to end.
- Enable scenarios (simply and basically)
- Take only a few innovative risks
As I think about it I have failed many times in following this philosophy, I enjoy taking risks as well as technology drives my scenarios in many instances.
As developers we know there is more than just writing code, something that business analysts do not account when trying to price your resource and time. We should get rid of all developers as Phil Haack fantastic blog post described. Hey wait, he is in our side on this one. Yet brings something very interesting into surface, programmers are not communicating effectively to non very technical person or we get frustrated to keep repeating or explaining the same concepts.
A developer is just a resource in a project, is not even the most important resource nor the one that deserves more attention, the developer in a project yet is normally the one that requires more time and budget to get the product to the customer.
Following the philosophy to build new application, developers and architects should spend as much time as they need to build an architecture and build prototypes proof the concept.
When architecting a solution we are eager to use the latest technology as well as not creating workflows from end to end. If you look back on your previous challenges you would be surprise to find out you took perhaps a few risks that increased the time and cost of the entire project. I’m not saying, that you should never take a risk, I for once take many risks in my projects and I’ll be taking more in future ones, I make sure to managed those by early prototyping and increasing the amount of time to avoid surprises, even with that, surprises will come, yet you’ll have the proper budget and time to deal with those as they arise.
This works for me besides my 2008 resolution, easy, flexible and always ready!
Some great resources to help manage your programmers ego.
http://www.secretgeek.net/program_communicate_4reasons.asp
Cheers
Al
Follow me in twitter | bookmark me | Subscribe to my feed | Add stats to your blog