| A random bag of advice based on my personal experience. 1) If you are recruiting and if you are attracting new recruits with phrases like green fields projects, bleeding edge tech etc stop doing that at least some of the time. The problem you have is partly a recruitment issue. Try and get at least one person who is content to be chugging through bugs, low level security issues, performance improvements, and test coverage. Having at least one person in the backroom who just does this stuff makes a massive difference over a year or so. 2) If you know that specific areas need to be reworked allocate a non-trivial part of your development time to do maintenance. That means shipping less new stuff. You have to be ok with not shipping some new thing in favor of re-engineering some internal system that no customer even knows exists. 3) If you don't know what unit tests, integration tests, and snapshot tests are you should learn. Figure out what your test coverage is like. Don't go nuts and start aiming for 100% but you can likely cover the majority of your code with automated testing. 4) When you need to fix a bug think about whether you can create a test. Create a test that fails while the bug exists, fix the bug, test now passes. That will prevent you ever reintroducing that bug. Don't be surprised if this significantly increases the time it takes to fix the bug but it pays off in long term stability. 5) Collect performance data. Look at it regularly until you have an intuitive sense of what normal looks like. That way you will know when it gets better/worse. If you can have a dashboard on a monitor showing stuff like average request duration all the better. If you can get stuff like error count, request volume etc on there too you will have gone a long way to gaining an intuitive sense of 'something is wrong' before anyone else notices. |