Developers are expected to ramp up quickly and contribute when starting on a new application. I’ve had to do this many times over my 20+ year career and I wish I had recorded my experiences for each one as it is such a good indicator of potential issues. I have always enjoyed asking new team members what their initial thoughts are. The longer you and your team stay on a project, it just gets harder to gauge how easily new eyes will be able to comprehend the code and getting that fresh look can be invaluable.
For my current position(now 2 years in), I was hired to support two applications written in two different languages, both of which I have had a good amount of experience with. One of these applications was created 20 years ago and the other just a year before I started. At first glance, the older had no set patterns or architecture along with 0 automated tests, while the newer was written using MVC and had decent test coverage. The interesting question is why was I able to quickly ramp up and contribute faster to the older application when both applications had a fairly high level of complexity? The short answer: architectural patterns can backfire if not used properly. I’m not saying I preferred working with the older application, there was a fear of breaking existing functionality and because of that extra developer testing was required. I should note that the application was near end of life and backfilling tests would have been a waste of time.
I plan to delve deeper into this topic over the next few(I’m guessing) blog posts. I hope I won’t just reiterate the downsides of pattern(s), but instead talk about real life scenarios where patterns have caused huge headaches.Home