My top ten list on how to succeed with large projects. (6)

Demand a TCO for system architectures.

Do you remember TCO? It stands for Total Cost of Ownership and was common in the nineties for corporation calculating the total cost of their computer and software investments. The calculus should not only include the initial cost of stuff, but also costs for management, licences, infrastructure, education, salaries etc. 

I believe it is time to take this paradigm to system architectures.

Architects and developers are usually geeks with an interest in their job. They like programming. 

And they also like everything that is new and hot and they are very curious about trying stuff. 

Stuff that stays interesting for a month or so until the next new cool stuff shows up.

Stuff that ends up deep in the architecture of the systems they create. 

Stuff that in the end can cost the customer a lot of money and what is bad for the customer is bad for the developers. (even if it can give them a longer project in the short term)

I don't mean that you never should adapt new programming paradigms, add third party libraries or use new patterns to build the software. System development is about evolution, otherwise we might all just stay programming COBOL.

I do however mean that you should think before you do it.

Think in terms of "How much do I gain by using this new stuff?", "How much will it cost?", "How much more complex will the code get?", "Can we find developers that know this stuff or will people make shortcuts and further degrade the architecture?", "Will this new stuff be legacy in a few years or will it stay?". "Do we really, really need this?", "Which are the alternatives?"

In short make a quick TCO-analysis. Don't just buy the buzz words without thinking.