What a mouthful. What does this mean, anyway?
A Case Study
We were involved in a project. A fairly involved e-commerce site on a shoe-string budget. The site was designed using ASP and Microsoft Access, and was run on a shared server. The owner quickly realized that the site needed to be moved to a local hosting service and put on a dedicated server for more control, and that the database was going to be inadequate very soon. However, the site had been designed around Microsoft Access, and had a lot of proprietory sql code.
The transition to the dedicated server was the easy part. While there were still things to be considered – the credit card processing API had to be moved over smoothly, and the data had to be tranferred safely – those things were minimal compared to the database migration.
The migration from Microsoft Access to Microsoft SQL Server involved a lot of sql code rewriting. And, because of the shoestring budget, there wasn’t a development server that these changes could be tested thoroughly on before going live. So the migration was done and put onto the production server, and the site experienced site-wide bugs and problems that took weeks to iron out. In the mean time, customers were frustrated, and the owner was stressed during the transition time while bugs were worked out.
The Difference is Planning
Planning for scaleability doesn’t have to be difficult, or even expensive. This same case could have gone infinitely better had the owner planned for the idea of upgrading databases. Simple, easy changes in how the code was written from the beginning would have make migrating virtually effortless, and reduced the downtime dramatically.
We Plan as a Matter of Practice
Because we’ve seen it time and again, we incorporate the principles of maintanability and scaleability in every project. The results are code that migrates more easily. Less code. And code that is easier to maintain.