Okay, I'm going to gripe about work now.
I've said before, a large part of what I do is ask my employer to do things they don't want to do. Most times, I'm asking them to avoid raining needlessly cruelty on their customers.
If I was being fair - I would say their opposition to my suggestions does not originate in a desire to be cruel - but rather a need to please their corporate overlord.
I haven't met many overlords, but they seem fixated on one message:
Hit your release date & don't go over budget.
These are good goals. I respect them. Because while there are and endless supply of worthy ideas, money is finite.
CorpWorld attempts to deal with a byzantine process that prioritizes the ideas that flow through CorpWorld like a river. As no champion of an idea likes to be told "No," any rejection is followed up by a rigorous search of the rules to maximize their odds of getting funded.
I am on one such project. It had a very simple idea - one that (without fear of violating my NDA) I can describe as
Let's do what damn near everyone else is doing. Or LDWDNEEID, for short. As you'd expect, the goal of this project was not to set the bar for the industry, merely to achieve parity with the market.
Parity is not sexy - yet somehow the battalion of fabulists behind LDWDNEEID convinced the Overlords to fund it.
This was over a year ago. We began assembling a team of experts in the various disciplines and walked our way through every modest scenario that LDWDNEEID would need to accommodate. We wrote stuff down -small stuff, core stuff, important stuff - and I drew pictures of what that stuff might look like (nothing too detailed, lord knows we hadn't heard back from the experts on what was technically feasible).
It is at this stage when a person like me can have the most impact. Early on in a project simple decisions can affect the DNA of generations of code. Just presenting an alternative early on can avoid crippling pain later on. Our entire team deliberated and we came to a modest set of improvements to the normal process. Nothing earth shattering, but we had our ideas - and they were given form and purpose.
Enter the
HiPPO. Now, your average HiPPO is a dangerous beast (they've seen it all, they know what they like, etc) but our HiPPO was absentee which compounded these problems. We had HiPPO by proxy. The HiPPO's minions would attend meetings in their stead. The minions would gamely make small decisions - but big things had to be run past the HiPPO.
So be it. Above a certain pay grade, people are insanely overbooked, so we were grateful we had been granted room to work.
Now, I'd said that LDWDNEEID was not a sexy beast - and sooner or later this fact was bound to come to the attention of the HiPPO. Right about the time we were set on a design, our herbivorous master issued a new directive,
People want more... we will add SpuriousFeature and PointlessBling to LDWDNEEID, and they will be happy. Counterarguments were in vain - so this was added to our scope.
I extracted one concession from the HiPPO: we would test these features on real users. There were two competing designs on how best to present SpuriousFeature. We would ask users which design they preferred: SpuriousFeature 1, or SpuriousFeature2.
Weeks (and thousands of dollars) later - the users showed a clear tendency...to not use the SpuriousFeature at all. They also did not understand why PointlessBling was part of LDWDNEEID.
These results were interpreted as a clear endorsement of SpuriousFeature1. PointlessBling's test results were deemed too inconclusive to rely on.
Shortly after this decision was agreed on, CorpWorld laid off a large number of people (including my
partner) and a large number of survivors changed chairs. The HiPPO was in a new chair - but their Parthian shot hit home. SpuriousFeature and PointlessBling were staying.
Also - we added Inexplicable Legacy System Constraint. This still allowed LDWDNEEID to accomplish its core function, but just barely.
Enter the Buddha.
At this point, LDWDNEEID was reviewed by another team I'll collectively call Buddha, who wanted it to look and act like other projects.
Again, I understand this goal. People don't like learning how one system works, they sure don't like to learn how ten different systems work. It is a good goal.
The result of Buddha’s review was to have the current project manager fired - and to completely re-imagine LDWDNEEID so that it was consistent with a project I'll call TinyApp.
Now, TinyApp is a fine app, but as you might expect - it is not very big. By contrast LDWDNEEID (and SpuriousFeature1/PointlessBling) was rather large and would have a very hard time being consistent with something designed around doing a lot less.
I pointed this out. The team agreed. Buddha was unmoved. We would squeeze LDWDNEEID down so it could be consistent with TinyApp.
We hadn't coded anything at this point, so this was a documentation change. I drew my pictures, tested the layout and came to the inescapable conclusion that it was impossible to include SpuriousFeature1. Not only that, but just converting the original LDWDNEEID to be like TinyApp would violate a slew of interface best practices.
I demonstrated this, repeatedly. Buddha was unmoved.
Then the cost estimates rolled in. Like magic, SpuriousFeature1 and PointlessBling were transformed from whimsical notions into line items that cost money.
They were out.
This was good, but again, the simple fact was LDWDNEEID still had major problems as it tried to be like something totally unlike itself. Best practices be damned. Consistency uber alles. Never mind that TinyApp was never designed to be forward compatible with other projects. It did not and would not scale to anything larger than itself.
Orders were orders, and we pressed on. Ten pounds of digital sh!t were duly crammed into a 5 pound digital bowl. And it looked and worked awful. I begged for a test. The interface had huge problems that might prevent people from being able to use it at all. Nothing doing. No test, we had a deadline and tests take time.
At this point - we turned over about half of our project team. With new faces come new ideas and retreading of old ground. This is both good and bad. To the good, we were given leeway to make LDWDNEEID as big as it needed to be (huzzah!) but new constraints were added to LDWDNEEID's core function. Instead of doing what damn near everyone else was doing - our new mantra was
Lets Do What Virtually No Sane Person Would Want.
At this point - a sober review of LDWVNSPWW
TM would make any thinking Overlord pull the plug. We would be spending serious dollars to position ourselves behind the rest of the market and (in my opinion) still fall well short of what our end users would want.
However, LDWVNSPWW
TM had acquired a destiny. We would build it, for we are dumb. Staff attrition had reached an appalling new low (our meetings were frequently three people, down from ten) but there was a date and it would be met.
I'd managed to get another test into the mix, right as development was starting (which is the worst time to find out it’s time to change things, second only to right after your go-live) and the results were appalling. LDWVNSPWW
TM was doing what no sane person would want and sane people asking us why.
We had no answer for that - only that we would try to get some minor changes into the code before things calcified.
With the onrushing train of go-live nigh - programmers start doing something that makes everything worse.
They read our documentation.
Suddenly there are all sorts of panicked questions about features we'd laid out over a year ago.
What is this? they exclaim.
All the modest interface ideas from last year are revisited - I am called by a developer to who asks if I can revise a specification. I defer to the client, who does not respond. The project manager demands immediate action - they will lose their resources if they don't get an answer now.
I hedge. If I change things and the client disagrees, I'll just have to change it back. I ask for a full list of suggestions so they can be reviewed en masse instead of bit by bit.
Over the course of my discussion it becomes obvious that the programmer is telling me what he's already built - and asking me to change the documentation to match it.
Because that make sense.
The client is faced with a harried manager demanding answers and raising the twin specters of increased cost and delay.
It's no contest. It never is. The client forwards instructions to make the specification match the existing code, in the interest of time. What no sane person would want - will now be that much harder to understand.
In a few days the clients will sit down to discuss the recommended changes from our test - and this same pantomime will play out again - this time followed with the fanciful promise of
perhaps in a future update, we could...
Then the funding will shut off. Meetings will stop.
Days later I will learn secondhand that a malformed parody of a modest idea has been inflicted on the world.
I'll go to a launch party and drink something strong.
And then I'll wait for another project.