Throughout my time in consulting, mentoring, and full time work I have come to notice a few signs that tend to lead to over budget, late, and failed projects. The intention of this post is to share these insights, hopefully with a bit of humor and it is definitely not to be taken as religious mantra. =)
Sign 1: “What We Need Is A Rules Engine”
This statement always hits me like the bell toll of doom. While I’m certain that there are scenarios that justify a rules engine the most common time I have heard this phrase have been from the small/medium business with a relatively low complexity application and worst of all, the statement appears before a single line of code has been written.
How can you possibly advocate something as complex as a rules engine when you haven’t even seen what coding patterns have emerged yet?
Sign 2: “We need to be Future Proof”
Once again, this is a problem at the start of a project. Once upon a time I was doing work for a company that was looking to design the next version of its internal software. Said software was a glorified database I/O application that ran just fine on a single server. The lead of said project demanded a structure that forced all of the developers to be remoting-friendly and spent a few months designing a back-end framework to wrap remoting calls to make them easier.
The extra (useless) work not only ran the project over time and budget, but also caused confusion to the developers since they had to learn a custom framework which supplied functionality that wasn’t ever being used.
Sign 3: “XML-itus / aka configuration hell”
It seems from time to time in organizations an architect comes along that is absolutely fascinated by the XML concept and wants to put absolutely everything into XML configuration files with the thought of designing this glorious application that never has to be recompiled again. Don’t get me wrong, I’m a big fan of web.config and configuration files where they make sense… this is a pretty limited scope for me though.
Once upon a time I worked on an application where lists, keys, etc were spread out in various xml files plastered all over the application structure. The end result is when you were looking for something you had no idea where to find it.
Once upon a time I also worked on a project where an “enterprise framework” required that all stored procedures be placed into a huge xml file with all of their parameter information, etc as child nodes in the stored procedure. The grand vision of this is that you could make changes without recompile, the grand reality of this was that anytime a database change was made you had to search this 5000 line config file to find the stored procedure and edit the xml config file as well as the database deployment. Can you say additional points of failure? Besides which adding or reading new parameters required logic changes anyways.
Sign 4: “Bringing Down The Enterprise Hammer / aka round peg, square hole”
Ah, the glorious enterprise framework. For some reason it seems like developers feel compelled to create vast frameworks for their organizations and that every project and developer has to use them. The flaw in this strategy is that the framework is often designed before the code that is intended to use it in which case the framework becomes bloated and often does not address the real problems end of line applications are trying to solve in an elegant fashion.
Common Frameworks should never be written before experiencing the real problem domain. Instead, developers should practice the following:
- Code Once
- When the code appears a second time notice it.
- When the code appears a third time, promote it.
In this way you let your problem domain dictate the common functionality you carry around.
Sign 5: “We’ll add staff later as-needed”
This is a big management blunder that I have seen many times. They under staff at the start of a project to save money, and plan on adding developers later if the project starts to slip off schedule. The reality of the situation often is that adding developers to a late project makes the project later.
To developers, the reasons for this are fairly obvious. When you enter a new project there is a period of low productivity where you are learning the ins and out of the existing application and determining what needs to be done. Non technical managers often think that a developer is like a phone support person in that all you have to do is put a body in the seat, give a few hour training session and it’s off to the races.