Can you prototype a complex system change?

Question

I'm currently in the process of redesigning parts of a large and complex application server to allow it to be distributed across multiple machines.

I've been asked to provide a prototype of the redesign in a relatively short time period.

I don't think it's possible to create a prototype of this; the changes are in existing code, and the changes are at such a low level that the system can only be in one of two states: working or not working. There's no middle ground. The changes have to be implemented all at once, because they all rely on each other. There's no way to partially implement all of the changes, the system won't work unless they're all fully implemented.

At this point, I'm unsure of what to do. I know that it's hard for others to tell without knowing every detail, but on a generic level, am I right in that something like this can't be prototyped? Is there some way to prototype things like this that I don't know about?

Answer 1

Seems to me that you can distinguish between the code that does the work, and the code that communicates between servers. Like the difference between Apache and TCP/IP. You can prototype your new communications network between the servers without having any higher-level working code. If there is an existing network operating OK then leave it alone and build your prototype communication network independent of that. Interconnect psuedo-apps rather than the real apps. That can be protyped and tested.

Another step might be to "wiretap" the existing system. When system S1 sayd "Hello" to system S2, your code X1 would see S1 say "Hello" and transmit that to your code X2 which then compares what it heard from X1 and what S2 heard from S1.

Not much to see on the screen, but you would be protyping the criticaal portion of your new system.

Answer 2

Is your application server broken up into micro modules or kernels (ala JBoss)? In that case you could perhaps prototype the minimum core being distributed across machines.

You'll of course need to make it clear that aspects such as remoting, messaging and distributed txns still need to be worked on but at least you'll have a start.

If you're talking about a monolithic ball style app server, then yes it's unlikely you can prototype this out quickly. In that case I'd suggest building a 'strawman' which represents the pain points of what you're trying to achieve. Hmm, that probably wasn't clear. For example, you could build a few classes representing a moving part of the app server (say transactions) and implement your distribution idea across that.

Answer 3

By prototyping do they mean an actual code prototype, or are they actually looking for a detailed design? Maybe they are looking for mock screens or interfaces and just calling them as protoptyes? If they are looking for a code prototype before or along with the design, it is a bad idea. Get the higher level design ready first and discuss it with your team/client. The go for the detailed design and interfaces. Convince them that doign a code "prototype" is not really possible.

Usually prototype or stubs invlove a great deal of coding themselves and should not be done unless you really need a "proof-of-concept": to show that something can(or cannot be done) (something like switching to a new library or porting an app). Or maybe you need stubs to implement higher level code without creating lower level code first. I dont know if this is your case but if there is no justified use for your prototype, oppose the idea politely but firmly.

Answer 4

It is very rare that problems can't be broken down in smaller chunks. The more complex the project, the more chunks it can be broken into.

If you were to design a distributed application from scratch, surely the end result will not be the first result you test. Just like when you design a video game for instance, you might make sure your basic video commands work, then work on user interaction, then work on bits of the game scenario... Same with a distributed application.

That said, a prototype, or a proof of concept, generally is not directly related to the application you work on. It is a simplified application which demonstrates the key requirements or design features that you plan to implement.

Whether a prototype or a proof of concept is a suitable investment or not is for you to argue with your boss, with your specific knowledge and situation. But generally I do not think that there are many situation when that is not possible. It may not be cost or time effective, or you may not know how to build one effectively.

Bear in mind that a prototype, depending on what you intend to prove, does not necessarily need to be built using the same tools as your finished product. Especially if you are only trying to prove the general concepts & architecture. If you can trim down the requirements to the smallest meaningful concepts that need to be tested to convince your boss to invest more, then you have the definition of what your prototype should be.

So your starting point before saying hey or nay is to double check with your boss what exactly worries them with the big bang approach (everything in one go). And see what you can do to demonstrate, in the simplest possible way, why it is a good idea to go ahead with development. If you can't do it with a prototype, you might be able to do it with simulations or by analysis (and build a strong business case).

Answer 5

Everything can be prototyped

If a problem appears to be too complex to prototype, then break it into smaller problems and prototype each of those.

---

However in this instance they mean they want to see will the underlying changes work, before you go and change the existing application.

You - obviously - can't do this in the existing app without actually doing all the work, so what they are looking for is a simple lightweight sample application (brand new code) that exercises the mechanisms that you will put into the existing app.

This new prototype should be as simple as possible, while still exercising the problem areas of the existing application (as simple as possible but no simpler).

They can benchmark the prototype for memory consumption / load balancing etc and prove that the effort to upgrade the existing app is cost effective.

Answer 6

Yes, you should prototype even large, complex software changes.

The old adage, "measure twice, cut once" applies here. From your prototyping, you'll gain invaluable understanding of the system behavior and of potential issues you may encounter in the real changes. What you learn may drastically affect the final solution! It is easy to think we've considered all the ramifications, but especially with large, complex changes we can't have. There are bound to be issues or dependencies we've missed. You want your final solution to be pristine and production-ready.

Michael Feathers recommends a similar tactic in his book, Working Effectively with Legacy Code -- scratch refactoring (pp. 212-213,264): "Just get in there," he says, "and start moving things around and making the code clearer...just don't check it in..." Do this to get a better understanding of the code and to elicit issues that you will have to resolve once you are ready to make the real changes.