I’ve taken over a legacy product in my current role and my job is with a new team to productise the good bits, drop the bad bits and make it so others can deliver applications and modules on top of the core with lower time and costs. It’s got quite a long history and was never really ‘productised’ and is about to become one of the core products of the company. It was developed by developers who were told to ‘just get it done’ which has meant that it’s devolved into a not so good piece of software.
This has got me thinking about the code I’ve worked on over the years which I think I can narrow down to three categorisations.
Bad code doing bad things, I think this comes from junior or naive programmers, the code is not understandable and it does things in what would be considered worst practice.
Good code doing bad things, the code is commented and understandable but it does something that gives you queasy feelings, eg sql injection, intermingling data access and presentation, no source control, no unit tests, quick fixes where no one’s really tried to understand why ….
Good code doing good things, the optimum, the code is well documented, efficient, semantically grokable and it solves the problem with the minimum of code and communicates and encourages good code to be built on top of it. Interestingly it’s usually less code in my experience.
I think over your career you write all three. It’s sometimes hard to admit, but at some point everyone has written bad code, it might not have reached production or you’ve gotten queasy half way through and taken a different approach, or it’s in production right now and it’s keeping you up knowing what a egregious hack it is. So how do you get a team writing good code to do bad things to be one where they write good code doing good things?
For starters start a review, mentoring and design process. I think often the bad things comes out of lack of time, lack of mentoring, lack of knowledge or sometimes lack of passion. Someone on the team has to understand technical debt and convey this to the business. People will in most cases try to do the right thing if given the opportunity. The ability to acquire and grow knowledge is a fundamental tenant of software engineering. For most passionate people in the industry they relish the challenge and if given the opportunity will take it with both hands.
Secondly start writing things down, start an operations manual for the dev team, start a wiki, communicate the how and why, build some organisational knowledge. If people coming into the team, especially graduates, can’t see the how then they’ll be doomed to repeat the process and never understand the why except from the hard lessons they’ll experience on their own. The scientific progress of human kind comes from standing on the shoulders of those who came before. If you’re not writing these things down and communicating them then you’re not part of the cycle of knowledge and people will be doomed to reinvention which is just a sad waste.
Play the devils advocate in reviews, don’t give people the answer but ask them how they would solve a problem with the implementation they’ve chosen, use a scenario to describe an extension to the problem or another view of the problem that their solution doesn’t cover. Ask how they could do this more efficiently, what about performance? This of course requires that you understand what it’s meant to do really well.
Always; positive, negative, positive. People respond better to encouragement than criticism, especially when creativity or passion is required to research and derive a solution. You don’t want new people on the team struck like bambi in the headlights.
These are some of the things I’ve found useful in teams I’ve been part of. I’ll be using some of these over the next 6-9 months to run the new team and reset the old habits in the delivery team so it will be interesting to see what works and what doesn’t.