Q1: Can you Code in Inception?

Can you code in Inception?

The answer to Q1 on the quiz is YES. The fact is, if anyone ever asks can you preform RUP Discpline X in Phase Y the answer will always be YES. You can preform any discipline in any phase!

So the real question is: When or why would you code in Inception?

At the simplest: if while the Architect is comming to undestand the vision, they see a significant technical risk, you may have to code in Inception to resolve this risk. More specifically, the technical risk area needs to have two characteristics:A. The architect is unsure that a solution for the technical risk existsB. If there isn't a solution, we really have NO project.

This is not common on most projects, so coding in Inception is not common either. But when this combination occurs, we need to address it by creating a _throw away_ prototype. There are two basic kinds of prototypes, throwaway and evolutionary. In Inception we focus more on throwaway prototypes, while elaboration can be seen as an evolutionary prototype.

In a throwaway prototype, we throw away the solution and seek to only retain the knowledge that something is possible or is not. With an evolutionary prototype we keep the solution and incorporate it into the actual deliverable product. Thus a throwaway prototype can be of low quality, since it will be scrapped, but the evolutionary prototype MUST have a minimum level of quality or it will severly impact our product. Remeber that the evolutionary prototype is created to address a high risk area. The last thing we want is for a solution to a high risk area to be of poor quality and actually part of the final system!

Many projects spend far too much time in Inception. Some of my clients have spent as much as six months, when unguided. The first iteration of Inception should be much faster, say 10% of your project schedule or three to four weeks, whichever is SMALLER. Four things can drive this number up: Specifically, stakeholder interviews, Architectural Proof of Concepts (APOCs), weak domain knoweldge (which leads to using the RUP business modeling discipline), or adopting a new process or technology set.

Since speed is of the essence in Inception, we don't want to slow it down by creating an executable that we plan on keeping. Speed and Quality pull apart from one another. In Inception we focus on speed, which means we don't want to keep any prototypes created there.

What if you wish to retain the solution? Wait until Elaboration. The fact is that if you think there is a solution, then you always wait until Elaboration. It is only when you are worried there isn't one that you code in Inception. If you truly think there may not be a solution, why would you slow down enough to make the prototype high enough quality to keep, when it may not even work? So you could almost add a C to the above list:C: You are willing to throw away the solution and retain only the knowledge that the risk can or can not be solved.

Finally, one best practice to manage your Inception prototypes is a best practice I learned while using the Spiral Model for software development: For every prototype, have a statement that says "This prototype ends when..." then finish the sentence. One real world example from a client was "This prototype ends when we can connect to the vault using a com object, extract a single doc property and display it to standard output." Having a crystal clear statement like this one will ensure that the prototype can still be managed, even if they are not following a disciplined set of standards (remember we ignore these, reducing quality, but increasing speed for Inception coding).

As an example, a manager can use this list to manage the prototype: Imagine the APOC (Architectural Proof of Concept) is trying to solve a risk. We create a sentence that says "This prototype ends when XYZ". Then manager can now go to the assigned resource and say: "Can we do XYZ yet?" If the answer is "Absolutely! But look what else it does now! It does A and B and C and D!" At this point the manager can reel the developer in. They've done too much! "That's great, but we only needed it to do XYZ. Inception prototypes are the critical path for Inception, so as soon as you get XYZ done, you need to stop and report this so we can move into Elaboration! Also, remember we have to throw away all of that work due to low quality, so while what you can do is interesting, it has increased scrap for the project!"

Another possible response to "Can we do XYZ yet?" is "Oh... XYZ... right, um, no. Sorry I've been focusing on A and B..." The developer has lost sight of the target. Actually, with a well written "this prototype ends when" sentence, this is less likely to occur, but if it does the manager can now remind the developer that XYZ is all we need to get out of Inception, and to refocus their efforts on cracking that nut, or proving it can't be cracked. They can elicit a new estimate and move on.