Delta T, which I will define as the time between when you hit f5 to compile and the time when you hit the breakpoint that you set in the code.
Anything that an architecture does that increases this must be carefully considered.
If your architecture increases Delta T without giving back something concrete and appreciable, it sucks.
Things that unnecessarily increase Delta T:
1. Too many projects in a solution.
2. Unnecessary deployment procedures - if it is more than hitting f5, it is probably unnecessary.
3. Peripheral projects that must be run simultaneously, or first - an 8 tier architecture with SOA? Failure.
If you didn't think about it the tradeoffs carefully or recognize that there are tradeoffs in any architecture, if you didn't ask yourself if you were making a mistake doing it this way, or if you thought you did something really cool and new: you did not, you just wasted everyone's time who ever has to maintain or develop on your application, you're costing your company money, and you annoy me.
No comments:
Post a Comment