The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.

- The 90-90 Rule, proposed by Tom Cargill

There's a classic, constant pull between the need to do something right and the need to get it done. I generally fall into the "do it right" camp, since that means I won't have to touch code I've written after I'm done implementing it. But earlier this week I had a meeting that made me question if doing it right should always be the goal, and whether just getting it done might have been the better solution.

The Project

We had a meeting with our users for a particular project, one that was supposed to run on a service-based engine already in use for some other web apps. This engine (let's call it the Process Approvals Engine, PAE, a wonderfully corporate-sounding acronym) is meant to define the steps in some kind of approval process; this person approves, then that person approves, and so on until everyone that needs to approve a project has done so. I explained this to non-tech people by saying "If you can reduce your process to a flow chart, you can use the PAE."

Apparently the design of the PAE didn't account for all kinds of flow charts. (Full disclosure: I designed, built, and implemented the PAE). Our end users wanted to have two processes running simultaneously, then tie those processes back together near the end of the project. We didn't have enough time allocated in the project to implement this kind of functionality in the PAE, and I wasn't sure I really wanted to anyway as I like to avoid scope creep. What the end users were trying to do was use the engine for an application that was (in most people's eyes) 90% similar to what PAE was designed to do.

We did our best to accomodate their process, showing that we could implement most of it using PAE, and also showing them the kind of limitations we had. But the independent-process problem lingered; that step had to be jury-rigged to work properly. I was still a little uncertain of this solution, but it did what the end-users wanted, so I made the app ready in preparation for the demo.

The Demo

The demo went fairly well, until the end-users realized that the app wasn't going to be able to enforce an order on those two independent processes. They wanted to ensure, programmatically, that the independent process was done before completing the main process. PAE simply wasn't designed for that scenario, and they weren't happy with the jury-rigged solution we'd implemented.

What I discovered after some digging was that the reasoning for wanting their process in parallel was purely for performance; there was one step that took a long time and didn't need to wait for others to start, but had to occur before another step later in the process. So because they didn't want to have one person wait on another when they didn't need to, the end-users insisted that the process had to happen in parallel.

We went back and forth over how to solve this issue for a long time. They wanted assurances that the independent task would be complete before the whole project could be completed; we said we couldn't implement that without heavy refactoring. After a one-hour meeting that lasted three hours, we as a group eventually determined that the tool, as it existed, wasn't going to work. Something had to change. I desperately wanted us to use PAE in the correct manner, so that my code and their process would be simpler and easier to maintain.

The Hijacking

I started to voice my concerns about the parallel-task problem. PAE wasn't designed for that, and I hadn't seen any technical or business reason that prevented the process from being totally linear. If the process was made to be linear, then PAE could support it exactly as it was designed to do. So I started pushing the end-users, seeing if they could redesign their process in a more linear fashion, so that we could PAE as it was intended.

They actually responded better than I thought they would. They thought about it, and said that yes, they could do this in linear fashion, as long as each group was given advance notice as to when a project was started. Since PAE already includes that kind of ability, I did a mental fist-pump and started congratulating myself on having convinced them to allow us to do it right, instead of doing it now. We agreed that the linear process would be simpler for everyone involved.

Now we were using the tool for what it was designed to do. I walked out of that meeting with my head held high, proud of myself for convincing others about the value of code written correctly.

In the Name of Doing It Right

That good feeling didn't last for very long. Almost immediately after the end-users left the meeting, I realized that I didn't take something into consideration. This was a very small part of their process that didn't fit into PAE's use cases, and I'd allowed it to rise up and overpower the rest of the process. I'd let the 10% dictate what the 90% did, and that didn't seem to be very wise.

My boss pointed out another problem to me. It occurred to him well before me that in about an hour I'd trashed a month's work from my team, and more work from other teams. We were all now starting over. We had to rewrite large portions of this app to follow the new process. All in the name of doing it right.

This didn't sit well with me. We'd gotten so close to a solution, and to fall short and have to start over was disheartening, even if I liked the new direction better than the old one. I started to wonder if the doing that 10% in the right way was worth having to re-do the 90%, and I'm still wondering that as I'm writing this.

I'm very sure that we could have implemented what they wanted using the PAE and jury-rigged a better solution, but I wasn't sure at all how difficult that was going to be to maintain and use. It would have been difficult, but we could have done it more quickly than implementing the linear process. But I talked the users out of it because I didn't think it was the right thing to do.

I'm not sure if this was a good decision. It's the right decision, that I am certain of, but I don't know if it is a good one. I allowed the 10% of the process that didn't conform to PAE to dictate what the rest of the 90% of the code and process were going to do. I'd delayed the project another couple months without realizing it at the time, and possibly made a lot more work for everyone involved. Was doing it right worth the extra effort, especially when we'd been so close to a solution? I still don't know.

What about you, readers? Do you want to always get it right, even at the cost of it taking longer than it would otherwise? Or are there some times when getting it done is more important? Let me know what you think in the comments!