Do your project managers complain that the developers can’t seem to get a reliable release out on time?
Do your testers complain that every time the developers change anything, another apparently unrelated part of the application breaks?
Do your developers complain that your project managers unreasonably expect them to estimate functional changes to an impossibly complex application, and then promise release dates to customers based on those estimates, with the contingency stripped off, as if the estimates were in any way likely to be accurate?
Do some developers react to this situation by point blank refusing to give estimates when asked, while others try their best to guess but invariably fail, and invariably underestimate?
Testable code is key to solid software releases, and automated regression tests are key to faster, better quality software releases.
But, code needs to be designed to enable automated testing in the first place. And the framework that the code runs on also needs to enable testable code.
If it is, this could be a big part of your problem.
ASP.Net webforms is one technology that majorly got in the way of writing testable code, and for a long time it was the only practical way to write web applications on the Microsoft .Net Stack.
Now I like Microsoft .Net, I’ve spent the last 20 odd years working with it, but ASP.Net Webforms was one thing Microsoft got wrong. It has led many .Net web applications down a slippery path to a quagmire of maintenance headaches that would eventually ensnare them.
Some years later, Microsoft realised that MVC was a better pattern for web applications and updated the framework to support it. This is now the primary way that new web applications are built in .Net. It is also the only way that building web applications is supported in .Net Core and future versions of .Net.
If you’ve been wanting to migrate your application from ASP.Net webforms to MVC, but struggled to come up with a compelling business case that the rest of your company can understand, think about this.
Migrating your legacy webforms application to MVC isn’t just about developing a nicer user interface using bootstrap, angular, vue or whatever your favourite UI framework is, although it certainly enables this. It’s not just about esoteric ideas like “cleaner code” and “better separation of concerns” that make your application code nicer to work on for developers, although it enables this as well.
It’s about rescuing your software from this maintenance swamp that is stopping you from developing your application features at the pace your business needs. It is also about keeping your developers and your project managers sane so they stop wanting to kill each other quite so much, which is always a bonus.
It’s about making your web application testable.
Think of it as an investment. You are putting the necessary framework in place for spending less time on rework, and more time developing the new features your customers need, and tests for them while you still remember what the requirements were. Once you have automated regression tests for the key parts of your software, your QA team can spend their time focusing on the new feature’s you’ve just built rather than manually testing all the existing functionality over and over again.
And if you’re thinking “Oh yes but our application is massive and that would take years and the business keeps asking for new features so we’ll never have a quiet period long enough to do it!” well you’re right of course, but it doesn’t need to be done all at once.
You can migrate your webforms application to MVC a page at a time, within the same project and switch on each new page along with it’s automated regression tests when it passes QA, and you can release it alongside modifications to other parts of your system as part of your development road-map. You can focus your development effort on the pages that are giving you the most pain, the ones you have to change most often and that are holding you back the most, so the benefits will start to come in after the first couple of releases.
But that’s a story for another day.