Papa's Perspective
It's Beautiful, But is it Sustainable?
Software, even the most beautiful software, needs to be developed with an eye toward those who will be maintaining it in the future.
We can design and develop beautiful software, and also make it flexible and maintainable. (This is the point where the peanut gallery chirps "Maintenance? We don't need no stinking maintenance!" Maybe you don't, but your company might.)
Developers face many choices when designing a multi-layered application. Some of those choices entail the layers in which to break the app into, the technologies to use for those layers, and the coding patterns to use. This can be a truly fun and invigorating process for many developers; it certainly should be. This is the time when developers can truly make creative and free-thinking decisions that shape the project. But sometimes it's also good for us to step back and make sure the application architecture is not just solid, but also flexible. Yes, the "F" word.
It Has to be More Than Art
As developers, we love to create beautiful code. On the way to creating this work of art, we often talk about how great a pattern is or how perfect technology X works with a layered approach. But that's the rub: software can be an art form, but is it good for the project and its company? I argue that it's possible to keep your creativity while also producing flexible and maintainable applications.
Consider that if you design and develop an application using a series of tools, patterns and frameworks that you may not be the only person to work on it. After it goes to production, will you be supporting it by yourself? The folks that manage the sustainment of your application should be well versed in how to handle break/fix, change requests and enhancements.
Just saying that you used MVVM, MVC or an ORM doesn't make the application flexible and maintainable. These patterns are great, but there are many ways to implement them. Did you implement them in a way consistent with other projects at your company? Does anyone else know how to support it? Those questions are pretty darn important to ask.
I've seen many applications go into production that were developed as a beautiful piece of art. Some looked and worked awesomely, with the developers touting their great patterns. But after the applications go to production, the sustainment developers are tasked with making changes or fixing problems. How do they tackle this?
Keep it Simple and Maintainable, Stupid
There are two good techniques. The first is to use the KISS (Keep It Simple, Stupid) philosophy. Design the application architecture to be maintainable. Think about the developer behind you. If someone else can pick your app up and run with it, that's a huge win for sustainment.
Of course, the trick is how to make it easy to run with while still maintaining solid architecture. What we do is hard, and you should expect that folks are at an adequate experience level to maintain the application.
The second technique is to set up a transition plan with the sustainment team. This can be a huge success if you include the sustainment team in this process, where you both decide on the level of detail needed in the transition.
Using either or both of these techniques, I've seen a lot of beautifully designed systems go into production and continue to be supported successfully. Without keeping sustainment in mind, the application's stability and total cost of ownership over its lifetime can suffer considerably.
About the Author
John Papa is a Microsoft Regional Director and former Microsoft technical evangelist. Author of 100-plus articles and 10 books, he specializes in professional application development with Windows, HTML5, JavaScript, CSS, Silverlight, Windows Presentation Foundation, C#, .NET and SQL Server. Check out his online training with Pluralsight; find him at johnpapa.net and on Twitter at twitter.com/john_papa.