Proof of Concept

In software development projects, vendors or integrators usually pass through a step called POC (Proof of Concept). This is usually still in the pre-sales period and is basically an activity wherein you try to prove or provide reasonable and substantial basis for the technical aspect of the solution that you will be proposing. And although some POCs are paid, others require them to be free. It is of course generally good if you get paid to do the POC, because even if the client chooses not to implement your solution, it's not a total loss.

However, when you do a free POC, you of course try to limit the investment of time and effort that you are willing to put into this task. After all... you don't really want to expose how you are planning to do the whole thing. Furthermore, nobody really wants to work for free.

Earlier today, I sat in a meeting to discuss an impending POC for a possible project. The goal was basically to try to understand exactly what we needed to show the client, and hopefully manage their expectations. As the meeting progressed, a lot of the details got spilled out and we basically managed to open a can of worms. The client had very unreasonable requirements. First, they wanted to subject the POC application to the same rigid testing that they use for QCing modules that are about to be deployed to Production. I immediately interrupted at this point and tried to explain to them the concept of a POC. It is certainly not a fully functioning module.... nor is it even a prototype. They failed to get the point. The juicy discussion went on until I began to hear clues about why they had these kinds of demands. Also, they didn't want us to change anything in the business process. Just move them out of the back-end, but keep the front-end. Long story short, these details came out:

1. The existing system had no technical documentation

This actually isn't the first time I've heard of this, but it still sends a cold shiver down my spine. It is fucking unfathomable. I honestly do not know, how a big software development company ever implemented a project as big as this (only 4 years ago), without following even the simplest development standards. No diagrams or other documentation whatsoever... just the source codes (all 175MB of it). And they are supposed to have already implemented a lot of projects for the Govt and MNCs all over the country and the region. Heck, I even applied for a position in that company once.

The guy I was talking to sounded like he was blaming the original implementor. And although I agreed that they really fucked up the design, my question was:

"Why the fuck did you sign the system acceptance in the first place? They probably submitted some sort of design proposal right? And they couldn't have gone forward without a sign-off from you right?"

Of course I never really asked these to his face, lest I openly expose him to everybody in the room for being the stupid piece of shit that he is. Does he really expect us to comb through 175MB of source codes to figure out what needs to me modified? Two words... KREY... ZEEE! Jeezaz... what kind of system requires that much code? I have worked on really big and complicated projects on heterogenous platfroms and have not seen code reach that big. What the fuck were they writing in there?

2. There are no longer any local support for the current system

This is really something that they have no control over, so this is really a valid point.

3. There are change requests continously coming in

I simply fail to see the real validity behind this one. Almost every software in the world eventually changes and is constantly being updated for modifications that have been requested by users. Does he think he is the only one that has ever dealt with a backlog of change requests?

4. They have existing investments in programmers for that particular front-end platform, 6 teams of 3-4 people.

This one is political in nature. If we change the front-end, the entire department composed of 6 teams lose the business justification to exist. They will have to hire new people, or train them in the new platform. Now although this is technically a valid point, you have to realize that the framework itself is flawed and has been a cause of major headaches for the past 4 years. And yet when it came time to migrate them out if the back-end, they chose to keep the front-end.

This really didn't surprise me at all. This guy was talking like a lot of programmers do. They complain a lot about their workload, but they don't want to bother changing the way they do it. And to a certain degree, this actually becomes a sort of bragging right to other programmers. It gives them a sense of pride to talk about what kind of hell they are going through for a particular client or project. This goes on until it becomes a comfortable niche. And even as they toil heavily and write codes that hack the existing codes, they subconsciously love the fact that they are actually doing it this way.

To explain this in paractical terms, let's say Program A was severaly flawed in it's design and is now generating problems for client X. Most of the times, rather than properly correcting the design, they will write codes that actually go around the poor design, gradually adding and compounding "hacked codes" into Program A. We acceftionately call them "permanent workarounds". After a couple of years, nobody knows which is what and everything is so cluttered that it's often easier to just scrap the whole thing and start from scratch. Sadly, this is a common practice that I see too often in a lot of software companies even today.

5. They wanted to roll this out in 2 months.

This was another jaw-dropper. I don't know how many times I've heard about this one. Often, the schedule is not dictated by the readiness of the solution but by something else. 2 months is fucking insane. And I am not gonna go kill myself and work long days and on weekends during November and December.

6. They have a limited budget.

But really... who doesnt right? Every fucking client is working with an approved budget. Again, most of the times these budgets were drawn without considering the scope of the requirements and they end up fucking screwing themselves up their own ass.

OK, so let's recap here. They want us to come up with a fully functioning module for their POC, which will be subjected to the same rigorous testing that they do for changes that they are about to deploy to Production. Note that the modules are interdependent. This will require us to put in a huge amount of effort specially because we were only given 3 weeks for the POC (notwithstanding the fact that next week only has 2 working days). Oh, and they will not pay for it. And then we are not supposed to change the front-end platform to protect their dumb ass investment, which is basically 175MB of code that is such garbage, that it is actually giving them a fucking headache to maintain. We have to be able to complete this and roll this out in 2 months, and be able to give them considerable leeway in the terms of payment and the actual professional fees. Hmmmm... what do you think? Looks like we have a winner right here...