Software: Rearchitecture Sample and How to Tips

I discussed in my previous post the value of separating the UI from the business logic. In this post I’ll give you some suggestions on how to do that.

It’s always easier to get management to sign-off on a large development project if you can demonstrate increased market opportunities, monetary savings, and improved revenue opportunities. But execution from engineering is critical. I’ve seen several rearchitecture projects that went bad because the person assigned the job of analysis didn’t really understand how to take the application apart and put it back together again. So the companies wasted a lot of money on a project that brought them NO tangible returns.

I’ve been involved with several successful product rearchitectures and I think the technique that works best is to assign a person to look seriously at the code and identify ALL the places that need to be changed. This can take months depending on the size of the application. I’ve never done this with an entire team doing the review but that should work if well managed. Make sure that all the places that need to change are identified and that there is a solutions plan that the engineers agree on. Do not take any action unless you understand the entire scope of the project. This is an engineering fix and shouldn’t break the application.

To rearchitect a product you have to understand what your objectives and limitations are. You have to understand both the technical and business aspects. These are your constrainers and they define what you have to work with. Once you’ve identified your box, you then need to identify what the real problems are. And once you know all that you have the knowledge you need to devise a rearchitecture plan. A good rearchitecture plan will reuse as much code as possible. Don’t reinvent the wheel, use what you already have. By doing this you can finish the rearchitecture faster with a higher level of confidence in the code base.

I think that it is vital that an architect not only understand the technology, she must also understand the business. A few years ago I joined a project that was two years late with no foreseeable end in sight. This was at a gaming company that made casino games. So embedded system, written in C, no nice debugger, EPROMs, and a home-grown OS. I was the only trained software engineer on the team, the rest of my colleagues were hardware guys. My boss basically said, “Get us out of this mess.” I spent the first 2 months fixing bugs and adding support for a UART and the configuration screen. This was time I spent familiarizing myself with the development environment, the code base, and the over all product architecture. I then spent the next 2 months identifying where the architectural flaws were and devising a two-phase plan (we could not have any downtime because the company was on the market). I then briefed the rest of the team on how we were going to fix everything. Seven months after I started, the product was stable and had been approved by the Gaming Commission for release.

I’ve seen an industry trend towards hiring architects that have no practical coding experience and I think this is a huge mistake. I see architecture as the place where technology and business meet. An architect has to have the ability to weigh the technical benefits and downfalls vs. business benefits and downfalls. Without practical product development experience I don’t believe a person can do that.

If you are considering a rearchitecture/refactoring project then make sure you have the right person doing the analysis. Choosing the right person can make you a hero and rain good things down on your company. Choosing the wrong person can make you a schmuck without a job.

Technorati tags: Refactoring, Rearchitecture, Architecture, UI,
Architect