0 Comments

Chad Myers' posted this post about making changes and trying to improve our profession. Here is my comments.

There was a time back then that blacksmith were forging metal to make tools, weapons, nails, etc. What the blacksmith was doing was not recorded anywhere and was true craft. What he learned, he passed this information  back to his students. With time, it became a science with predictable results.

Building software is a little bit how blacksmith were doing tools 300 years ago. We do have some methodology but none are guaranteed to give a successful software. I've seen lot of developers who just code away the features until the software works. I also know developers who are proud of what they do and try to improve the way they build software.

I find it really sad that people try to kill a methodology that produced one mistake or a failed project. Each methodology have their own benefits and disadvantage. Waterfall development have their place (believe it or not) when the requirements are fixed an will probably never changed as it is often the case in code that will go inside hardware or into outer space (see this article about the NASA software development for the shuttle). Agile is mostly good inside business with requirements that change along the way (80% of all development?). But the methodology is not the only thing to blame. There is unskilled developers, inexperienced team leader, unrealistic promises/deadlines, salesmen that promised more than the team could deliver, etc. All those elements can bring down a project whatever the methodology you are using.

On the Usage of tools

Tools can get you so far as where you want to go. Tools can't help you decide on where you are going. That's why I believe in ALT.NET. I don't care where the tools come from. If it's not ready and reliable, I'm not using it. Entity Framework looks good but guess what? I'm not using it for production. Too early. LINQ? Solid enough. For data mapping, we use LINQ to SQL for simple scenarios but I've used LLBLGen Pro, CodeSmith NetTier, SubSonic (not NHibernate yet but I promise I'll give it a try). Notice something in this list? No tools from Microsoft beside LINQ to SQL. DataSet and DataAdapters were nice but were not flexible/extensible easily and hardly fitted inside your model.

Whatever is done, bad technology choice can also lead to a project failure. We are far away from a methodology choice.

Conclusion

I totally agree with Chad on this. Much is left to do. But before we can make our craft a science... we must keep on trying new methodology, gather success AND failure. We must learn from every choice we make.

Without this, we're only going backward.