The Release

Friday night, 11:58 pm, Eastern Standard (or Daylight) Time: 2 minutes to bring your production site down for the latest upgrade.

You have slogged your behind off to meet your ‘code freeze’ deadline. The new development process is challenging and stressful. But you have pulled it off. Post code-freeze, your QA has given you enough hard time to open several ‘Hot’ or ‘P1’ bugs. It just seems nothing works. Your project head is aghast. He yells in the regular bug meeting, ‘what the hell did you guys do?’. You know you’ve worked hard. You know you had some ‘known issues’ going into code freeze. But this is bad. It seems QA is bending over backwards to make you look like an incompetent fool.

The pre-release days are hell. Every bug is carefully monitored. It’s like having a camera in your bedroom and the whole world tuned into it. Of course some people make a pretty good living out of it. But not your friendly neighborhood software programmer. See, software developers despise micro-management. No matter how bad they are and how good they think they are, the last thing they want to feel is the constant breath of the project leader on the back of their necks. But anyone that worked in software development knows: Code freeze period is the time for extreme scrutiny. Every code check-in has to be approved. Nay, frowned upon. For the developers themselves, it’s an embarrassment. It’s like you are being caught out stealing. And those daily calls at 4 pm Pacific. Aargh!

And then the final week arrives. There are still 4 HOT bugs. None of which are yours. But those guys are never called out. They seem to get away with murder. A typo on your screen is an international incident but a null pointer exception for that team is brushed off saying, ‘can you take care of it by release date?’. WTF? Were you an adopted child or something?

Come the day of the release, you are literally hyperventilating. You signed in to the conference call and the chat room. There are all kinds of stuff going on in the chat room. You see the text, ‘I think John was supposed to take care of that’ and you fall off the chair before you see the other John has already responded. There are all kinds of noises in the conference call. Kids yelling, dogs barking, people sneezing and sometimes snoring. Everything. The meeting organizer’s repeated, ‘please mute your line if you aren’t talking’ falls on deaf ears.

Among all this, you are almost certain your piece of the application is going to break and either put you out of job or worse, be the ridicule of company wide email thread. That last bug you fixed 4 days ago, you didn’t get a chance to test the corner case scenario. Shit! It’s going to ‘blow up’ your application. You hurriedly sign in to your development environment to start testing that use case. At that time, you hear, ‘OK we’re live!’ It’s 2:15 am Saturday.

You type in your URL. It says, ‘Unable To Access’. Your fingers are now shaking. It’s mid-December and you are sweating like it’s 95 outside. You are not sure why you can’t even get to your page. Did your last check in go bad? Did the India team check in anything at the last minute without your knowledge?

It takes a few moments to realize you weren’t signed in to VPN. Phew!

Finally you take a moment, sign in and get to your URL. It is working just fine. You test out several use cases. Strangely, this is all too smooth, too good to be true. You wonder if you are on the correct site. You double and triple check. Your QA tester meanwhile has already filed a bug saying she cannot see the data. For the umpteenth time, she uses the test user’s credentials that does not have the right set up. You feel like you could break her neck right now! But decide against it as she’s located in Minneapolis.

Finally after 45 minutes of frantic testing, you figure everything is just fine. In fact, more fine than during development and UAT.

By the time you hit the bed at 3:45 am, you wonder if all that stress was worth it. You decide it was, considering the pay!


Designer vs. Developer

After years of letting the business group – with input from the customer – decide how the UI of your applications look like, you finally get a proper UI designer. He has taken several courses in UI design, usability, accessibility and several other -ilities. He’s super fast with Photoshop, can crank out a ‘quick mock-up’ during your design call and you are generally very excited as a developer that at last your product, your baby, on which you’ve spent countless hours and written thousands of lines of code, will finally ‘look’ nice.

It starts off great! Your first few meetings go well with the UI designer. You are excited by the ‘look and feel’ and the ‘consistency’ and the ‘ease of use’ of your product. You actually end up saying something like this to your manager, ‘You know John, bringing in a UI designer is one of the best things to happen to our team’. That’s the first positive thing you’ve said about your team in 3 years and 9 months.

Then the application development begins.

Like Kim Kardashian’s fake marriage, your relationship with the UI designer begins to crumble. He wants a ’rounded’ drop down. You know your IDE doesn’t support that. He wants a ‘tree’ structure. You complain it’s going to be a performance hit. You talk code, he talks art. You sit in your little cubicle coding your brains out, he comes back from a week long seminar in Copenhagen to lecture you on the ‘latest trends in UI design’. It keeps getting harder and harder.

Isn’t there a middle ground?

There’s no real short answer to that question. Well, yes there is. The short answer is No!

The primary difference is that he is paid to make your product look great. You are paid to make your product work. There was only one person in this world who could put both in one package but he died of pancreatic cancer last year.

The key is patience. Developers are programmed to think ‘logically’. Designers are not. The first step is to make them understand the business. Half of them come with lofty ideas that fall flat because they are totally unsuited for your business. So making them understand the business, the key elements, and especially the limitations is a key step. Failing this, your relationship is headed for divorce.

That is the easy part. The tough part is to make them understand the limitations of the programming platform you’ve chosen. Snazzy tools cost a lot to buy (and more to maintain the license). Open source tools are generally crappy in the flair department. But as said before, the key is to be patient. Don’t expect the UI person to understand everything upon the first conflict resolution. They need to be nurtured, and the limitation you mentioned in the team meeting yesterday, you need to repeat it today and Monday and the next month as well.

On the other hand you need to understand that he’s trying to make ‘your’ ugly product look better. In the process covering up some of the obvious flaws. Give him some credit. You’ll end up being happy and sleeping peacefully.

BTW, I have not met a ‘he’ UI designer so far.