I've worked in a number of huge ugly repositories. I am somewhat impressed by how well I can work with unorganized code bases. I think its something of a special skill gained from years of contract work. I think it helps in debugging code of any quality. Hopefully you dont have to work through such code. Even more I wish that if you do have to work with a large unorganized code base that you get the chance to refactor some of that code to make your life easier. One piece of advice for getting the time to refactor code is to not mention the refactor at all. Add the refactor time to an estimate when a feature adds to the poor code and tell no one. It is not often that product or project managers will grant an engineer the time to do anything that does not involve making money or fixing bugs. Software seems to adhere to an iterative methodology. Not just individual functions and classes but all the way to how we build teams can benefit from an iterative approach. Code refactoring is one practice that I hope to see taken more seriously in the programming craft. This process can greatly improve the performance of the engineering team and can be done in an iterative way. I hope that this process will one day replace the "hackathon".
Ive seen hackathons be a complete waste of time for a company. They can give developers a nice feeling of free time but often its unclear what to code during a hackathon and how long a hackathon should be held (I once worked at a place where the hackathon was an entire week). I personally like the idea of hackathons. A serious product, and competition in the industry should be a concern of all employees. Hackathons remove the focus of trying to make the best product from the work day and instead allow the developer to be creative. My experience is that this has been more of a marketing tool to get developers to accept jobs (we do hackathons every quarter) rather than an effective strategy to introduce features that are backed by the engineering team. I like the idea of hackathons, but in practice little of the coding during them seems to make it to the product. They seem way to make the developer feel pampered. I dont want any favors from my company I want a paycheck and an opportunity to create a great product that will be successful and solve a real world challenge. If the company wants to invest in tinkering it should put some resources towards a Research and Development department that will have a clear path in adding to the product.
I think a more productive process that should happen on a regular basis is a code audit. A code audit is a time to look over your code and think about what technical decisions you can make to allow you to add features and fix bugs more efficiently. During a code audit you should not only be fixing code but also fixing the process with how you deploy code. How can you make deployments faster? How can you make testing simple? How do you deploy database changes to production? How can you improve your staging server? A code audit is not just a time to fix ugly code its a good time to fix any part of your process that hinders you from creating a quality product or slows down that process. I haven't see this done as a scheduled event for development teams but I think its more important and can make developers happier than hackathons.
- 1) Teach and apply code style: If you dont have a common code syntax in your team then you should create some simple rules and during a code audit try to apply that syntax. This can be a simple start to seeing where logic can be refactored and making the code easier to maintain
- 2) Fix bottlenecks: User a code audit to do some profiling and find out where you can improve application performance.
- 3) Standardize process: document and create scripts to make deployments and common coding tasks easier and consistent
- 4) Create tests: one part of having an audit is being able to prove things are right or need to be fixed. Using this time to make tests for your code gives you something that you can use going forward to keep the code working
- 5) Refactor code: sometimes code is a mess and you just need to rethink how the logic is implemented. One of the worst things you can do during a code audit is create bugs. Things should only get better from code audits. When rewriting code make sure that you are not breaking other features and that your change makes a positive impact on how the code performs , is used, or how it can be maintained.
Approaching code refactoring as an iterative process makes it a much more practical task. Product managers have profit and feature creation to worry about and dont want to waste expensive developer resources on anything that does not produce end user features. That is not their fault and it is often very vague what the benefits of a code refactor will bring. Dont try to do it all in one sitting. Plan it out first and separate all the necessary tasks into small chunks. This way you can iterate on improving the code base and more fast without breaking things.
