Currently the best way I know to develop software is to grow it using TDD and Mocks*. Even if your team uses TDD and Mocks, there is a still a risk of you building legacy code.
The quickest and easiest way to build legacy code is to have a team of smart developers who write code that is smarter than the people that will inherit it.
Some organisations like banks have a standing army of “smart” developers. Other organisations do not have a standing army and need to bring in consultancies to build any strategic system. In doing so they may be building instant legacy applications as the consultancies will be building an application that is “smarter” than the developers who will be supporting it. The consultants may use thought processes and techniques that the team supporting the application are not familiar with.
This leads to the risk of legacy code that cannot be supported or changed. Parts of the application will become no-go zones that are coded around. Solid lumps of gristle in the application. Tests will break and go red but no one will care. All of this will lead to code that is hard to change, slow to change and subject to regression.
As you build an application, you need to build the team that will support it. Invest in the team as well as the software.
I’m sure others can share examples of how they do this.
* Check out Steve and Nat’s book on growing code guided by tests.
The IT Risk Manager 
July 26th, 2011 at 9:15 am
So the lowest common denominator should apply?
The consideration put forth here is real, but I still think it’s worth pointing out that it’s not TDD or mocks that will create the situation, but rather the disconnect between the creators’ and the supporters’ ability.
Thus, the risk is organizational, not technical.
August 5th, 2011 at 12:29 am
I haven’t worked out what TDD and mocks have to do with this. More fear-based sensationalism. Moving on
August 5th, 2011 at 8:03 am
JB
Your comment indicates a fail on my part. I am updating the post to more clearly reflect what I am trying to get across.
Thank you for pointing out the lack of clarity
Chris
August 5th, 2011 at 1:11 pm
Aha! I understand better. TDD/Mocks do not represent a panacea. I feel sad that we find ourselves in a context where it pays to state that explicitly, but here we are.
I used to think, in these situations, that “they” should stretch and learn what I know, but I now find that attitude unnecessarily one-sided. I no longer see this situation as a failing of individuals to learn necessary skills, but rather a collective failure of the system and the people in it to prepare the organisation to adequately maintain the source code after the original programmers have departed. The “first wave” ought to warn the decision-makers that it might happen, and the decision-makers ought to take that warning to heart.
That said, I don’t think I could design a system without TDD/Mocks, so when you hire me, you hire a specific maintenance challenge that you need to take seriously. If you meet the challenge, though, your reward is a safe-to-change system whose version 7 can still be built upon its version 1.
Thanks for clarifying. Legacy isn’t what we build initially, but rather what happens next
August 18th, 2011 at 10:47 am
[…] Growing instant legacy code with TDD and Mocks « The IT Risk Manager https://theitriskmanager.wordpress.com/2011/07/05/growing-instant-legacy-code-with-tdd-and-mocks/ […]
February 14th, 2012 at 11:06 am
[…] Growing instant legacy code with TDD and Mocks https://theitriskmanager.wordpress.com/2011/07/05/growing-instant-legacy-code-with-tdd-and-mocks/ […]