Every rewrite project has opportunities in it. Opportunities to improve your development process, your build and deployment strategies, your third party tools and libraries, even our choice of language can come under scrutiny (except for when you have to move because of the language you were using!)
There are also opportunities within a rewrite that can help the rewrite project itself and make your life easier supporting that rewrite after it has successfully completed, because the decisions you make during the rewrite will go on to bite you for a long time afterwards if you make them without exploring all the possible outcomes.
One way to make sure you cover as many possibilities as you can is to prototype. By this I don’t mean do a quick rewrite on a small part of your project and see if it works, because doing this will only give you a false dawn and make you think you’ve started your rewrite before you’ve even considered where to begin.
What we have done, and what I suggest everyone does prior to rewriting a single line of code, is to take all the third party libraries you intend to use in your rewrite, the version of the .net framework you will stick to, the IDE you will use, the database tools and providers you need, the development style and driven-development method you intend to use, and add in the process of how our rewrite will run.
Obviously it’s difficult to see into the future and yes, you can’t plan for every eventuality, but you can get damn close and realistically you should have a good idea of how you intend to put everything together before you start.
Now, with all that knowledge and information, find a problem within your own company that can be solved with an eventual product that is on the same delivery platform as the product you intend to create at the end of the rewrite – ie; don’t write a web-app when you need to rewrite a desktop application! Then, go ahead and write it using all of the areas we discussed above – use a database if your eventual rewritten app needs a database, use a third party WinForms library if you’re writing a WinForms app and intend to do so. Remember to think about all the little extra things you might plug into your rewritten product. Will you use bug reporting software? If so, include it in your prototype app.
But here’s the most important requirement of all for your prototype – make sure it is something that people will use because the knowledge you will gain from this prototype is invaluable and if no-one is using your prototype you will not get that knowledge.
If you can, do more than one. Or better still if you are asked by a client to write an application then use your rewrite methods and all of the above to develop their app (just remember to tell them it might take a little longer and knock the price down a little) – as I say, the information you will gain from the prototype stage is absolutely invaluable – you will learn so much about how your processes and tools do or do not stick together.
For example, we did three prototypes and from the first one we realised that our chosen UI tool was not going to cut the mustard. On the face of it, sure no problem, it looked good, it did all we wanted to and the support seemed great. We took a trial, even bought a license but as soon as we got deeper into what we were prototyping we realised that there were certain elements that we were going to have to tinker with. Had we started the rewrite and bought licenses for the entire team we’d have had no choice. We’d still be tinkering and possibly working around bigger problems as a result of that tinkering. It might have taken us a year to find the problems in the rewrite because the plan wouldn’t have got us to a specific stage quick enough to realise the inherent difficulties in this ‘chosen’ UI library. So we had to look around at other vendors.
Thankfully we found DevExpress and I’m so glad we did as they have been second-to-none with their customer support. The power of the libraries are immense and the tools they provide, not only in the product but also in the after-sales; things such as the webinars, the training videos, the reams and reams of documentation and the people, not to mention the excellent CodeRush. There is a very big reason why DevExpress were awarded the Best Software Development Tool Award at TechEd.
Had we not done the prototypes we would have stuck with the cheaper UI tools and we’d still be working around the problems today.
I’d like to point out that I’m not employed by or paid-in-kind by DevExpress. I have no ties to them apart from being a loyal customer.
I find that the challenge with prototyping the way you describe is getting your client/co. to agree to pay for something that ultimately could be thrown away.
Do you have any tips in relation to getting the client/business buy in?
If you can find a problem within the company that you can fill with the prototype then it won’t need to be thrown away. For example, we needed a simply time-monitoring app for storing support calls and tasks that are a result of that call. Most apps available were far too complicated or required high levels of set-up, so being a software development company we did what we do best and wrote our own. We still use the app today.
If there is a good chance the solution you have found will result in an app that will get thrown away then my advice would be to look for a different problem. You’ll only get the really useful information from an app you will continue to use.
So you’re not going with the prototyping that is often associated with the agile practice of “make a decision at the last moment possible” which often results in multiple prototypes being created and most thrown away, e.g. trying multiple technologies/approaches and picking the one that fits the best.
Are you saying only prototype in situation where there is a “hole” to be filled, so any work you do will be kept regardless? if that is the case do you not run the risk of the prototype becoming the production code?
I think this could be down to confusion over multiple uses of a prototype method. The idea is to create an application that is completely separate from your rewrite but one that uses the same tools, processes, classes (as much as possible) as you intended rewrite.
For example, our time app used an Oracle DB, a set of classes that we thought we could build on and a set of UI tools (that we dropped as a result of the first prototype then rebuilt the prototype using DevExpress). The time app is not used anywhere in our rewrite project but is used by the rest of the team, to this day, for logging any support queries which result in them doing other tasks.
This means that the code remains separate from the rewrite but what is learnt from the prototype is kept and used again.
I guess, for clarity, you could rename my prototype idea into “Doing A Mock Rewrite, without the Rewrite” as it does seem to confuse with the prototype idea in agile.
@cjm55 @MarkDalgarno @RGDevOps http://goo.gl/E13eQ is worth a read (by @FatherFil on prototyping before rewriting)
That makes more sense, to me at least, but you do have touches of the agile practice what with dropping code after first prototype.
One final question – how do you decide what tools, processes, classes, etc that you are using? Do you prototype those first or are you using existing artifacts?
We went into our rewrite having scouted some existing third party tools and built the first prototype with those tools, thankfully we learnt a lot and changed tack. Classes are generally coded to give an idea of what we might use. The first prototype needed a DB connection so we build a class to handle the data objects coming from that and methods to handle connections, disconnections, interrupted connections, pooling etc. We knew we’d need to control printing and would need grid output so we used those elements of the tools too.
In the next prototype (separate app – we never threw away the code, all three prototypes are still in use today; two within our team and one by a client) we built upon those classes or refactored them.
Deciding which areas to concentrate on was done by selecting which areas were most important. Which areas could be considered near to single-point-of-failure, then develop an app which uses those areas strongly.
The one thing that I’m still having problems “getting” is that you said you created prototypes which are still in use today.
I’m guessing that your idea of a prototype is different from mine, my prototype is similar to demo code, no error handling, logging, etc where as your protoypes, I’m guessing, are production strength fully tested etc, is this correct?
The difficulty I’m having is working out what you’d call these applications as they don’t seem to fit under the category of prototype as I, and possibly a lot of other people, would understand it. This is especially true as you have said the several have effectively gone into production and you haven’t mentioned any additional work to make them production ready.
What are your thoughts?
It’s an interesting point, and yes I agree, the general picture that comes to mind when you think of prototypes is a very loose, mocked-up “kind-of” app with very little error-handling, no logging and a flaky UI; all put together to test some level of code.
I think that prototypes, in whatever context or development stage they are used, are still prototypes. Our applications were prototypes of the rewrite process. Other prototypes may be prototypes of specific app modules, or prototypes of a process model, but they are essentially there to do the same job.
In our prototypes we needed to know how the code would work together so we had to put in error handling and logging. It was a good way of making sure that if we had chosen to use a third party tool to record app instances and errors then we would have had to make sure that it would sit happily with our chosen UI tools and our database provider. Whereas with a simpler prototype you may have just put them together to see if they work, we found we needed some real-use statistics and also some further tests to make sure that deployment wasn’t going to be an issue.
I guess what it comes down to is the length of time that is normally spent prototyping. By solving real-world issues with our prototypes it was easier to give the go-ahead on them. It also meant that the prototypes had to cover areas that in a normal prototype might have been missed, thereby including the elements that other prototypes don’t include.
Now it’s fair to say that our prototypes were rough and ready mock-ups to begin with and the first versions of them, whilst usable, didn’t look very nice or have all their bolts tightened. So, yes, there was a certain amount of additional work, but our prototypes were there to prove the rewrite process had foundations and that our chosen processes would all work together harmoniously. All prototypes are there to prove something, I guess the difference here is that what was a prototype for one project, the re-write, was also, at the very same time, a production project for a real-world in-house problem or client request.