OhJesusGod
I'm sitting in a conference room when the tonnage of the situation finally hits me.
The Builder is laying it all out - and I'm converting into real world.
A customer walks into a store, looks at a TV on a shelf...
Customer: Looks like a good set. How much does it cost?
Rep: Well, there are a lot of possible configurations. If I know exactly what options you want - I can give you a more accurate price. I need some personal information first.
Customer: ....
Rep: (Smiles wordlessly)
Customer: Can I get a ballpark figure?"
Rep: I don't want to mislead you with a guess.
Customer: Okay, here's my name and address and... (scans list of options disinterestedly) Okay, I'll have this one option. What's the price?
Rep: You need to choose a payment plan.
Customer: I'm not buying, I just want the price.
Rep: The price depends on the payment plan you choose.
Customer: What if I chose the basic payment plan?
Rep: The price would be higher.
Customer: But you would give me the price?
Rep: Yes.
Customer: And I could change my mind later if I wanted to buy, right?
Rep: No.
Customer: What?
Rep: Well, technically you could, but you'd have to leave the store and come back first. And you'd have to provide your personal information again - and pick your options.
Customer: Okay, that makes no sense.
Rep: Well, from my point of view, it makes perfect sense.
Customer: Obviously, you are a total idiot. Goodbye.
This is the scenario I must stop. To be precise, this is the scenario that a team of professionals must stop.
Also, to be fair, from a certain point of view - this scenario
does make sense. This would be the same point of view where Obi-wan tells Luke that Vader killed his dad and
isn't completely full of sh!t.
I digress.
Left to its own devices, CorpWorld would happily barf up big hunks of stupid like this - and they would just happen.
To prevent this, CorpWorld employs teams of people who push back on these ideas and try to present how the customer would experience them. This is not a specialized discipline, either. Loads of people have the same initial reaction to ideas like these.
Why the F$#& would we do that? It's totally stupid!
Sadly, veterans of CorpWorld have learned that pushing back on stupid is thankless and endless toil. Oh, they'll still have their initial reaction -
It's totally stupid! - but then they'll lay back and let it happen.
But laying back on this stuff is not what they pay my group to do. We propose the obvious solution:
- Instead of asking the customer to pick a payment plan before they see the price, DON'T.
- When they ask for a price, show them the price without a payment plan.
- If they choose to buy, show them the payment plans and their respective prices and allow them to pick one.
Obvious, yes. But it is a grave mistake to assume that this change will be technically simple - or embraced by the decision makers.
Many, many meetings later - we have convinced the Sales group of the wisdom of this approach. They control the public-facing web application and they agree that choices about paying should wait until after the end user has seen a price
and tells us they want to buy.
Wheels go into motion. Any web app is going to hook up with a back end, and just because we can make the changes on the front end doesn't mean we can accomplish this in the back-end systems.
The primary system we need to deal with is the Mothership. Mothership is a beast of a system that is simultaneously replacing numerous legacy systems and absorbing huge changes to its offerings.
And they're not done coding.
And we're connecting to them. They are a massive, upstream dependency written in 50-foot letters of fire.
We meet with Mothership, explain what we're up to and what we want. It takes an unbelievably long time, but we get approval to do what we ask for.
We will ask for payment options later in the process.
Huzzah!
All this means is that our app will do this and when it talks to Mothership it will not blow up.
Which is good, but there are other things we need to address. Like a lot of web applications, just because you think you've started a single process doesn't mean you are dealing with a single system. Frequently, a single task involves numerous systems and subsystems. One of the systems that our particular task will hit involves a subsystem that I'll call WeSaySo.
In order to accomplish what we want, we need to ask WeSaySo to make a change to a set of controls. Currently, those controls support two choices. We need them to support four.
Hardly a deal breaker, but in secure online environments, things are never simple. We meet with WeSaySo, they are not receptive - but eventually they agree to support what we are trying to do.
There will be four choic
es. Huzzah!
Fast forward a year. We're six months from go-live.
You think I exaggerate?
I. Do. Not.
My team is called in to meet with WeSaySo again. Since everything has sign off, I don't have to go. I leave it to Spock and the Machine. The Machine is awesome. I want to be them. They have everything organized, remember
everything, and are unbelievably nice to boot. Spock is there to destroy your stupid ideas. They
live to find questions you have no answers for. Clients fear them, developers stand aside when they pass.
Whatever WeSaySo has to say, they can say it to Spock and the Machine.
The Machine returns from the meeting to inform me that WeSaySo
won't add the additional two options to their application, thank you very much. We're all mystified, since they clearly indicated that they would. A year ago.
This is the Machine's area, and they crush it. Follow up meetings are held, sign offs are reviewed and WeSaySo's upper management agrees with us. Yes, they will add the two options.
Months go by.
We meet again with WeSaySo to discuss some error messages and their rep, ISaySo, questions us - again - about the additional options.
We cannot add these to our application. We don't have the budget. You should move these options back into your application - we have some suggestions about where they should go.
Um...
Spock and the Machine go to town. We - again - point out that these decisions have been made, twice now. And we - again - discuss the reasons behind them, in hopes of winning them over with logic.
WeSaySo is not interested in logic. They appear interested in preserving their application as it currently functions. No changes, no hassles, no additional expense.
What is remarkable about the repeated exchanges we've had up to this point is their consistency:
- Each begins with No, we will not change our application.
- Each ends with Now that you've spoken to our management, yes - I suppose we can do that.
- The period between meetings is used to utterly forget item 2.
- Another meeting is then scheduled to discuss item 1.
At this point, wheels above my head go into motion. One of our bosses has dealt with WeSaySo before and they've had it. They call a big meeting to review - yet again - what is being asked for and what has been agreed to in the past. This will be a room full of our folks and (significantly) both WeSaySo's management and ISaySo. [It should be noted that WeSaySo's management appears incapable of reining in their subordinates, or even of realizing that they are on different pages.]
We are geared up for confrontation and I've been asked to show visuals on exactly what we want and explain it all again.
WeSaySo is all sweetness and light. They say what we're suggesting is fine. In fact, they have some other changes for the page they would like made as well.
Would we mind mocking up how the page would look with these changes?
They go on.
Also, we've been asked to make this other change by our common client. Can you mock that up as well?
We're like...
Um.... sure. I mean, this is your application and you've been resisting any changes like you were defending your children, but I suppose if these ideas are coming from you, you must be okay with them.
So we do that. Mock up some quick and dirty versions of how the screen would look with their changes.
They're good with it.
Then we get an email from one of WeSaySo's developers. Rather, we are forwarded a message from a WeSaySo developer sending ISaySo a message that says:
The screen will not allow us to add these additional options. There simply is not enough room as you can see from this screenshot.
The attached screenshot shows the existing screen layout with four options with the longest label text they could think of gunking up the page. You can practically hear their glee:
Guess we can't do it. Sorry. *smirk*
Unfortunately for WeSaySo, they've sent this to the Machine. The Machine pulls together yet another meeting and I get a greenlight from our manager to mock up a page like a person would if they
wanted this information to fit and - Lo, and behold! - it fits with room to spare. I do a half dozen versions to show there are numerous ways to do this.
The boss loves this. WeSaySo's management does as well, they say their team does as well.
ISaySo? Not so much. They respond with a list of new requirements that the screens must meet that (strangely) never came up before, despite the fact that they impacted the very suggestions made by - you guessed it - ISaySo. Most are trivial copy changes but one is a requirement to include Button B.
Button B is useless. This is self evident. It is redundant interface that would highlight an additional unhappy path to the user. Unhappy paths will always outnumber the happy path, but you should highlight the happy path and try to lower the visual impact of all the unhappy choices. Besides, all of our screens have a Button A, which performs essentially the same function.
ISaySo is convinced that this particular page needs both Button A and Button B. We try to reason with them:
But they do the same thing...
ISaySo is not moved.
Button B actually does a little more than Button A. We feel having both is better for the end user.
We move to hard data:
We've run metrics on Button B. Virtually no one is using it. Virtually no one is using Button A for that matter, but considerably more people use Button A.
We send this to ISaySo and copy as large an audience as possible. ISaySo submits to the data.
Since metrics support this, I can support removing Button B.
Deep breath.
The other item that ISaySo has a problem with is the error validation treatment we've put together. We've asked WeSaySo to make their screen look like our screen and display errors like we do.
WeSaySo's current error message treatment highlights fields with errors (which is good) and displays message text that (and I'm not making this up) appears in a grey box at the bottom of the page that says - in effect:
Information is missing and/or wrong.
A user who scrolls down to read the error message is told two very different things: one or both of which is true. The user who keys on "missing" when they've entered data is going to wonder what is missing. The person who focuses on "wrong" is going to wonder exactly
what is wrong.
WeSaySo's current application will not tell them this.
Obviously, this is crap user interface. Everyone can see this, right?
Not everyone:
Since we're trying to keep our costs down, we want to keep the current error treatment.
Okay, a second ago, ISaySo was arguing for a totally redundant and unused Button B on the grounds that it improved the user experience. Now, ISaySo's against making clearer error messages because of money?
Before any of our team hits send on their respective rants - our client blasts an email to everyone:
The error messages will look the same on all screens. Make the change.
I could kiss them. I threaten to. They tell me to stay away from them - they like me as a colleague...but, stuff like that. WeSaySo's developer responds with a smokescreen:
But...We'll need to increase our estimates! But the client says 'fine' and end result is that WeSaySo will adopt our error messages.
We limit it to this:
- look like our errors; and
- distinguish between "Required information is missing" and "Required information is present, but invalid."
Huzzah!
We move on. At this point, flush with success - we (foolishly) identify Field X as a completely useless piece of interface within the WeSaySo application. We ask if it can be removed.
Before we're through asking we-
NO!!
We ask why this is so. We're told there is a technical reason. We speak to WeSaySo's technical resources and are told that - actually removing Field X would make their job
easier. It really doesn't do anything other than change an element on the interface - something that can be done based on other user inputs.
Okay. We revise our mockups and remove Field X. We have a meeting to review this fact and other development issues. ISaySo says nothing, but their developers have lots of questions. We write down a list of items for moving forward.
And we go forward.
Weeks later, out of the blue, I get an email from one of WeSaySo's developers:
My clients are asking why Field X isn't there on your mockup. Can you send me a revised mockup? Thanks.
I'm like
What? Field X was removed. You know this.
ISaySo jumps in.
What makes you think Field X was removed?
Because it's useless. There are other ways of doing what it did, and because you were there when we discussed taking it out.
ISaySo disputes this. Claims we never involved them in the discussion. As the discussion was in person and (foolishly) we did not email notes with the mockup immediately after the meeting - we have no hard documentation of this fact.
ISaySo's developers come to the rescue, they point out that they can accomplish the Field X effect without actually having Field X. ISaySo eventually relents, but is clearly not happy - and fires off an angry email to our manager about leaving them out of decisions affecting their application.
Deep breath. I make the rounds to all the WeSaySo developers and make sure they had the same understanding we did. Field X was coming out. They are not upset. They think the change is good. As a matter of good form, I mention to my manager that I should go talk to ISaySo and smooth things over.
Coincidentally, my manager is about to do that very thing and asks me to come along.
We arrive at ISaySo's desk and they are there pouring over printouts of the mockups I've made. They are comparing the ones with Field X with the ones that don't have it. There are a host of marks and comments on every sheet of paper. ISaySo does not look happy.
My manager starts in with a mea culpa: "We're sorry this mix up happened - it was never our intention to leave you out of this process."
ISaySo responds with,
No, no, I'm sure this was all a misunderstanding. Going forward we should make sure to copy everyone in on the discussions.
We agree.
ISaySo agrees that removing Field X is actually a good thing, and they are pleased with how the screen will ultimately look. They were just concerned because they had done some work testing the old design and will now have to do it over.
We completely understand. And we apologize. There is music and soft lighting. My manager is about to offer up some goodies from our candy tray-
Now about this Button B...Why did you remove it?
*Record scratch*
Uh, come again?
Button B. It used to be on the screen. And now it isn't.
Soft lighting is gone. ISaySo is pointing accusingly at my updated mockup where - the horror! - there is the complete absence of Button B.
I'm mentally rewinding to ISaySo telling us we can remove it. I'm looking at ISaySo's screen and (I am not making this up)
ON THEIR F-ING SCREEN is the very email where ISaySo is telling us we can remove Button B. Their exact words are scrolled off the screen, but it is absolutely the same email. I am certain of this.
The thought that ISaySo could have this on their screen AND simultaneously be questioning why Button B is missing breaks something deep inside my brain. My higher logic functions begin eating each other:
But, but, this is the same person who...
...and now they're saying...
..What ARE they saying...?
I respond with the same logic we used in the past.
Button A does the same thing. And.. no one is using it.
I have this foolish hope that this will jar ISaySo's memory and they will reverse course.
No, they plunge ahead with their full blown re-run:
Button B actually does a little more than Button A. We feel having both is better for the end user.
At this point, my manager is ready to give up the ship. They've come to bury the hatchet over Field X's removal. This is why they are bowing and scraping before ISaySo. They've never heard the Button B discussion and they are not up for another row. They're looking at me with a "wrap this up" expression - so I opt to abandon diplomacy.
We took it out because the metrics said no one is using it - and everyone was okay with it.
WHO was okay with it?
I finally point to the email on ISaySo's screen.
That's the email with the metrics. Scroll down.
They do, until they see their name followed by:
Since metrics support this, I can support removing Button B.
Instantly, their demeanor changes. They hurriedly open up an email from their lead developer (which I note is WSS dev lead saying, "Look, here's something else that is different!") and tell them to hold off - that they actually approved removing Button B. ISaySo apologizes for the mix up.
My manager and I exchange pleasantries with ISaySo, and walk off - feeling very pleased with ourselves.
So, we move on. The (surprisingly problematic) issues of "Add two options," "Remove Field X" and "Remove Button B" have at last been conquered. WeSaySo developers will meet regularly with our team and everyone can get back to working on other things. And we do, for weeks.
I keep asking the WeSaySo dev folks if they need anything from us. They assure us that things are fine. They'll let us know. Most of their folks seem like a good crew. They smoothed out the Field X issue, and seem eager to make things work.
A week before a development deadline, two hours into the day, I get an email from WSS dev lead:
Do we have to include these elements in our code base?
They're referring to some additional code that will make the application function for the disabled. I view this code as trivial markup. If they include it - verbatim - as we put it in our example, everything will be fine. I say yes, we need to have this. Six hours later, WSS dev lead responds to me - this is ten minutes
after close of business - they've copied in all of my managers, all the developers on their team, and their manager.
Our development environment does not support these new elements. I don't feel we should have to support them since we haven't in the past. Also, other applications like ours don't use them.
I'm apoplectic. This is a technical issue that is surfacing
the week before deadline. I get an innocent question and the first pushback I get to my answer involves everyone's manager. Given the previous acrimony, once management starts putting on their war paint nothing will get done.
If they'd asked me first - if they allowed our team to help them...
But no, we're really doing this. I try to head this off as much as possible before management starts reading their email. I speak with our dev guys, make sure I understand how big of a deal this is. Our dev says it's not. I set up a meeting where we tell the WSS dev guys this.
One of the cooler WSS dev guys is after me before the meeting to provide him with some scripts. I'm puzzled by this, since:
A: he's working in his own environment
B: he is a developer
C: I've pointed them to our application that runs all the scripts that create the effects we want him to emulate; and
D: he is a developer
I want to help, so I tell them I'll see what I can do before the end of the day.
But the day turns into meetings and I email back to say I won't be able to help him out. I send along a copy of the script they were asking about.
I'm in the middle of a meeting - mid discussion when I see the same WSS developer, along with WSS dev lead walking with a purpose towards our dev guys. They look agitated.
After my meeting I go check with Ace, one of our dev ninjas. "What did the WSS guys want?"
Ace is a code god, a total pro, and - impressively - an articulate and entertaining communicator. He says "Those guys wanted me to write them some scripts or something. Y'know... They kinda sounded like they thought
we were D-Business."
-Bit of explanation here. My group is essentially a group of developers, analysts and testers building our application. We make what the Business asks for. We are Makers. We do not ask for things to be made.
The WSS group are also Makers. In CorpWorld, we are the same. We both get our marching orders from the Business. Within the Business, there is this little subset I'll call D-Business. This group wants to be Makers - they have the chops, but they don't have access to core systems so they can go hogwild.
D-Business does interface. And they don't believe anyone else on earth is capable of making interface. If you get a project with D-Business, they will supply the interface. The Makers will supply the back end, period.
Soon as the words are out of Ace's mouth - my brain launches into a series of synaptic detonations:
- WSS has been under the impression that my group is D-Business
- If they think we are D-Business, they are assuming we are providing the interface...so....
OhJesusGodAlmighty...
WSS has not built the interface...This would explain why they have been asking for scripts and styles and file locations to connect to. We'd assumed they were silent about the interface because they had it well in hand...
...For three weeks they've been assuming the same thing about us.
...So we have no interface. I go to a WSS dev asset and confirm this. The Asset is appropriately embarrassed, which shows they are human - but doesn't help in any tangible way.
F*#$...
The meeting with WSS development follows the day after this realization. We meet with WSS dev lead, the Asset and another dev guy I'll call Stud. At this point, throwing a (perfectly justified) screaming tirade won't get us closer to done. WSS dev is pretty hangdog in the meeting. I bring Ace as backup to lay out his solution to the environment issues - but Stud is way ahead of us. "We're not trying to shirk work. We're just never been allowed to make the interface. We'll build it, we just need the time."
We promise to give them the time. Our managers will be insanely angry, but whoever builds the interface - building it will take more time than we have.
We do the only thing possible: we miss the deadline.
But now WSS development is born again. Stud is a whirlwind of coding awesomeness. Stuff starts happening.
Finally... We can get back to-
The Machine comes up to me, Spock's behind them grinning. "Seen your email lately?"
It's from ISaySo. Of course.
I would be fine with that.
This is their response to an email thread that they've looped us into - at the end. They are responding to a question from their WSS dev lead about an error message.
Wha...?
Reading down through the thread, the full sequence is this.
- A week before this message was sent, ISaySo wrote a really, really long error message and sent it to their clients for approval
- Yesterday, their clients (disinterestedly) said "fine."
- This morning, ISaySo sends the message to WSS dev lead; and
- Seconds later, WSS dev lead responds saying "The message won't fit in the new error treatment they are asking us to build. I'm assuming you would like us to re-use our current error treatment?"
You remember their error treatment, right?
Information is missing and/or wrong.
Well, apparently,
NOW they've come around to thinking that perhaps a specific error message is needed, only it needs to be a paragraph. WeSaySo has only seen mockups of our error treatment where the message is a single word.
Essentially, ISaySo is telling us:
Guess we can't do it. Sorry. *smirk*
*Huge Breath*
I write the email I want to send - then delete it. Then I take their paragraph error message and plug it into our error treatment and - Lo, and behold - it fits just fine - because our coders and designers aren't total idiots.
I screenshot the resulting message - convene a meeting with ISaySo, WSS dev lead and our shared clients. I show them that the error will fit and that we can proceed.
ISaySo submits to the data. WSS dev lead asks about a dialog that they'll need to have if their screen is to look like ours. Admittedly, I hadn't considered this bit of interface, so this is a very legitimate question. With the client there, I confirm with the client that they do, in fact, want WeSaySo to have the same dialog. Then I tell WSS dev lead that I'll check to see what we're doing for other applications like them and get back to them.
WSS dev lead starts firing off detailed technical questions about this dialog - pertinent questions, asked impertinently. They don't want to build a duplicate of our stuff. They want to point to our existing stuff. ISaySo begins taking issue with the wording on the dialog, they would like it to say something different.
With a supreme effort, I manage a calm voice.
We will look into how we can minimize duplicate coding.
I don't even get into the wording thing. First off, we didn't write the damn dialog text. The Business did. We were told to use their text - and we did. I don't give a sh!t what it says, save for one thing: The dialog should say the same thing regardless of what app is serving it up.
Meeting adjourned.
Later, the Machine and our Client confer and tell ISaySo the text will not be changed - WeSaySo will say the same as the rest of the application.
***************************
Still with me...? Good... 'cos by now - any sane person would have given up. Hell, I almost did. Spock and the Machine were tag teaming on bucking each other up at virtually every other turn on this. One of us would say "F$%#-it, I don't care anymore. These idiots are just not worth the hassle."
Here's the thing: Even a modest canvassing of the CorpWorld landscape reveals that this is not an odd case with WeSaySo.
Everyone we relate our story to says exactly the same thing.
Oh, *those* people, they are ALWAYS like that. What is their problem?"
It is tempting to assign sinister motives to people you have professional disagreements with. The Button B incident established my initial hypothesis about ISaySo:
they are overworked, disorganized and have a bad memory. Honestly, I've been there - I have said one thing one day, and the opposite thing on the following day. It happens. What distinguishes ISaySo in my eyes, is that they do not bother to nail down the facts of the situation before they go to DEFCON-5.
On Button B - were I in ISaySo's shoes - I would like to think I would have
read and re-read the relevant emails about the situation before I launched into a tirade about how it needed to be there. I say this, because when Field X was questioned - I poured through every bit of documentation we had and found we were missing hard documentation of sign-off. Then I did my best to work out a solution (aided by the Asset and Stud) and I went over to apologize.
When you are overworked, as ISaySo clearly is - there is the omnipresent fear of missing something you are responsible for. Mostly because it keeps happening. It is no fun, and it can make a person plenty frustrated.
This is my working hypothesis.
***************************
Where were we?
Ah, yes - the dialog and its text. I go to find out what we're doing for other apps that need to show this dialog. I check in with Rico Suave, one of our resources embedded in development for external apps. Rico will have this same issue and is totally competent. I'll ask how this dialog was addressed and hopefully this will be something WeSaySo can use.
Rico looks at me with a blank look. A dialog? This thought has obviously never occurred to him.
Do you think you could build a component that other apps could hook into, to avoid re-work?
Rico appears mystified.
You want me to build a service for a frickin' dialog? I'll just build it. It will take almost no time.
This is a useful reality check. WeSaySo is whining about building duplicate code - which is a valid complaint, but we're talking about a truly small bit of code. Plus, since our application is already externalizing the text in an easily editable file that can be accessed from anywhere - content and formatting will be externalized. All they build is a skeleton.
Seriously, WTF are these guys whining about?
I spend some time getting the CSS for WeSaySo's stuff parked in a common spot and reach out to the Asset to let him know what I think we'll need to do for the dialog.
I get IM'ed from Stud. Stud's way ahead of all of this. He's built everything as a stand alone and wants to know if he should hook into our content. I tell him I'll get him the references he needs the following day and thank him.
He's fricking awesome - I want him to seize control of WSS in a bloodless coup.
Dialog: handled.
Big exhale from my group. We start to move on to-
I've consulted with my clients and this is the wording they want.
Attached is a single line of text that is 80% identical to the existing text on the dialog. ISaySo has included an email chain where they have done an end run around our client and have separate approval from the business for this change.
At this point, I lose it.
The working hypothesis needs to change. ISaySo is clearly in this to win this. There is no way on God's green earth that a rational human being would care this much about one line of text.
The fact that they are being as passive aggressive about it as humanly possible is the hard evidence. Every bit of the text approval process pointedly does not loop in our team (despite our earlier hatchet-burying promise to include everyone in communications).
I examine why I'm mad about this: is it because I must win? Truly, I don't give a flying crap about the text. If the Business wants new text throughout the process - I'm fine with it. The Builder (my team) is looking for a reason to drag our feet - and I pointedly tell him this is a trivial amount of dev time from us.
Seconds. I tell them.
We are not going to dig in on this. They wanna be petty, fine. But this is not something I'm suiting up for.
The Builder nods - then points out that the language ISaySo has carefully gotten approved contains a factual error. One consequence of asking for approval from people who don't care - is that they don't bother to check it.
So this text will need to be changed - and approved - again.
The Builder takes this on and delivers the new text to everyone, ISaySo included, as a fait accompli.
ISaySo squawks again - but submits to the data. The text was wrong.
I totally don't give a crap at this point. I'm busy updating the numerous bits of documentation that have to change to support this.
You think I exaggerate?
I. Do. Not.
But since this is the windout - there's no point in whining now.
- Field X is gone.
- Button B is gone.
- Clearer error messages will be displayed.
- There will be a consistent user experience from end to end
and - most importantly - the reason we started this mess in the first place -
- we will have two additional options so the user won't have to pick a payment option before they see the price.
The next day.
Zero walks up to me. Zero is the Mothership liaison and usually deals with Spock and the Machine. They're out of the office, so Zero's talking to me.
"Question." Zero has a voice that makes James Earl Jones sound like a soprano.
"We are to be passing four options to WeSaySo?" Also, Zero asks questions like Yoda.
I say yes.
"BlackBox will not allow us to send four options."
Of course, there's a hitch. The BlackBox is a mysterious system that sits upstream of the Mothership. The BlackBox does one thing- and it's close-hold secret with armed guards. You do not question the BlackBox, and in years of working at CorpWorld, I have never been able to speak with anyone who actually works on it.
All our interactions with BlackBox are, in theory, handled by the Mothership. When we've asked for things, we've asked Mothership. Our four options will require BlackBox to give us more that what it usually does. Normally, each ask will get two bits of data - we want four. We'd asked Mothership to accomplish this by asking BlackBox twice.
"BlackBox will not allow two calls."
You're saying this is impossible? I ask, forgetting that Zero always answers this question the same way:
"Everything is possible."
...But...?
"But BlackBox must change."
Zero smiles. So do I.
There is no way - on any circle of hell - that BlackBox is changing anything. They are mysterious and unknowable and their floors are carpeted with requests for new features. If the stories are true, they sometimes respond to these requests just so they can kill the hope that briefly follows.
We are done.
We have a follow up meeting with the Builder and the Business and everyone agrees that the situation is terrible. That the end user experience is terrible.
Why the F$#& would we do that? It's totally stupid!
The Builder and I sit in silence as Spock and the Clients float some trial balloons.
We can save this, really. But the Builder has done all of this before the meeting. The Builder's discovered that behind the Mothership there are actually two other systems that have only just learned of what we wanted - and they are not happy about it. Pre-emptive blanket denials are inbound - costs must be contained, and altering these legacy subsystems is not within scope.
The fact that we had asked for - and previously been approved for - all of this work counts for nothing. Mothership is still being built and its connections to subsystems have changed over time. Once - about when we asked - these changes were possible. Now, Mothership has evolved and these things are no longer possible. At all.
Had we not spent endless hours locking horns over trivia with WeSaySo, we might have found time to do setup work to make this happen with Mothership's hidden subsystem teams. But that's only conjecture. It may never have possible in any tangible way.
Sure, we improved the interface for WeSaySo and preserved a common interface - but that will be it. We wanted four options and we will get two. The user will be expected to make a payment choice before they see the price. And they will be held to their choice going forward.
Blooded and wiser for it - the Builder and I sit quietly while the Clients and Spock play out their fantasies.
My opinion of the end result hasn't changed:
It's totally stupid!
But at this point, I'm going to lay back and let it happen.
