Build Products as you would Run a Race
When I was training for running a half-marathon years ago the most important advice I received was to overtake people on the hills. I never understood what that meant until the day I was running against 2,000+ participants in the race. A Half-Marathon is a 21km race (Canadian), in practice trials I had run two before the big race with the number and chip. When the race started, everyone took off very quickly, I had no idea why but thought I would stay with the group, then when we turned around the corner, out of site of all spectators everyone slowed to their respective paces. And herein came the first lesson that I observed.
Lesson #1: Run your own race, don't put on a show for people - you only waste your own energy on activities that could be in direct conflict with achieving your own.
So the race continued, I set my pace, moved forward doing my own thing. I had never been in any kind of race like this before so it was completely new to me, I kept on going - blocked out all the people passing me - set a goal to stop every second drink station and walk while I drank (mainly because I didn't want to drop gatorade all over myself) and pushed on.
Lesson #2: You will not know everything, so start with something, set measureable goals and move towards them.
Then came Kilometre #13, it was at this point in the race that I had 8km left and I decided to start picking up the pace. I didn't come to not give it my all and not hurt the next day. But how and where? And then I remembered the key lesson that made no sense to me in training - "take them on the hills". And I did, when the ground was flat, I kept my pace, but when the inclines started to come (and many did), I pushed past people, many people. How did I do this?
Lesson #3: We all have a natural tendency to slow down as obstacles are put in our way. The thing is, so does everyone else, so the best time to put that extra pedal to the medal is when everyone is faced with the same hurdle. Changes in the product platforms, adding new features, etc.
Building products is very different then building a startup, you might be sprinting in the early days of a startup but you can't sustain it forever. Building a great product is extremely different and requires you to find your own rhythm, set your goals and power through the obstacles.
Gmail and Reader go BOOM!!!
Oh Google... what did you do... how did this happen?
Did you hear? Google updated their Google Reader and Gmail applications this week to use the same interface consumed by Plus. We'll leave the whole native GMail app on the Ipad thing for now (completely different topic). Google gets points for trying to go the way of the common look and feel between their applications but loses massive points for applying it blindly.
In my first summer co-op job I worked for a local government department building their first website, inside of a department (which was inside of a department, inside of another bigger bigger department, etc, etc). Everyone loved it, it looked great, accomplished what the internal users wanted it to do and met the needs of our external user base. Before we deployed it, we were stopped and told to completely change it to follow the common look and feel standards of all the other departments and it morphed into something that did not address the group's needs and looked completely different (but the same as everything else).
So is Google like some great big, unmoving government agency now? Probably not, but 20 minutes of QA probably would have saved the backlash they got this week. Let's look at each app.
GMail
Take a look at how I "get" to configure my calendar in GMail after applying one of the themes... see it... barely... I even highlighted it for you. But you say that is just the theme, well I have news for you, it doesn't get *much* better, and really why provide something that looks like garbage and is completely unusable just for the sake of saying you have choices? With all the themes in Gmail there are only 2 I can really use before gouging my eyes out.
Things don't get much better with the main view, it looks like a bunch of colours on a page, compared with what I had before, it looked like an inbox that I could easily orgnize my email with (also notice the prominence of ads at the top of the page now). So my inbox got crappier, but my ads got more pronounced? Notice where I circled below, the CSS style does not completely line up.
|
Here is what I had before I went to the "New Look";
|
|
|
|
Here is what I have now (I kid you not);
|
|
|
Seriously... the inbox is bigger on its own (same emails), the adds are more pronounced and the top email does not even apply styles correctly? I have predominantly used the web interface for GMail, because up until now, no other apps could measure up to it but this past week has me seriously considering re-installing Thunderbird.
Reader
Um... well... what's to say... it's really white with these light coloured buttons all over the place. I can't really remember what Reader use to look like, although like GMail I do remember more broad colours and outlines to what I was reading - I could easily process the beginning and the end. I guess the appearance of a scroll bar for my feeds was a real annoyance so now I get this hover thing which comes in and out so that's not too bad. Did someone just learn how to do this little trick? Is that the new blinking icon thing? What is interesting is the Subscribe button remains constant all the time, but it is probably one of the least used buttons in reader. I'm not adding 25 new feeds a day, every day, I have about 50 feeds (which even then I feel is a lot to manage) and this button is always there. What is curious though is why does this button stand out but the most commonly used ones do not? Again, the page looks like Plus, but Plus is showing a lot more different information - friend photos, chat navigation, stream information at the top, whereas Reader does not. So right now I only have to deal with this very blaise style which I think is ok I just have to atune my eyes to figuring out grays from whites.
So what happened?
When designing something fresh and brand new there is something you ALWAYS need to do - run it by someone, run it by friends, family, your dog - get feedback. And if you start getting - "Oh yeah it's great, you're the best, I want to lick the colours off the screen" - dig deeper, what do you think of this button, what about this colour, what about this icon. Find the guy/gal who are critical about everything and put them in a room with your app. They are the people who will help you elevate your app. I worked with this guy who was not a UI developer but he understood UI and when he first saw one of our new WPF apps, he ripped it to shreds and logged 30 bugs in the span of an hour on top of sending out a massive email missive to the whole team on what the application was missing.
And with that we found our GateKeeper, a good gatekeeper will wound your pride and make you ship a better product, a bad gatekeeper lets you ship useless themes and updates that make the app worse then it was, but will tell you that you did a great job.
What is so sad about this whole roll-out is that this is the card that Microsoft has been throwing at Google in the "Cloud Wars" for the past year - rolling out updates with no thought to the impact on users. To date, I never got the argument, never cared about all the changes that I received (which I always took as nice enhancements to the individual products). But with this move, Google has played right into that argument and given Microsoft a gimme on the platform deployment from.
Hopefully this isn't an easter egg "splatter job" that Google has thrown out at us, and if so... nice work Sir Google, nice work indeed.
When Sales and Design Collide
Software Design is a funny thing - it's where developers want to spend the majority of their time to make sure they "get it right" while in contrast it is where the other Sales want the least amount of time to be spent (or in all fairness where they want this phase to accelerate past Mach 5). I have seen these holy wars break out in boardrooms (and yes I've been apart of them) but at the end of the day if you look closely both sides are trying to mitigate the same thing... the unknown.
In most cases I have seen the conversation (or been part of) go something like this;
Random Sales Dude (RSD): Why is the design taking so long?
Random Dev Dude (RDD): I don't understand all the variants of the problem. I'm going to need to build some of this to see how things really come together.
RSD: FANTASTIC! A product demo, that's just what we need, alright when can I show someone.
RDD: Well... ummm... it's just plumbing work really, I was going to have a form with two buttons and just proof out the idea so I know which way to go.
RSD: No, No... I want to show this feature and that feature and one of these whirling things.
RDD: Well, that's going to take more time, to do it right I'm going to need to...
RSD: No, No... Don't worry about that we're just going to show it to the customer, just slap it together, if they are happy with it we'll go forward with it.
RDD: Um ok.
Fast Forward 2 Weeks later.
RSD: XYZ inc loved that demo you put together.
RDD: What demo? Oh you mean that hack I did... yeah that was pretty funny.
RSD: Let's put it in the next release... ASAP!
RDD: WTF?
I'm not saying all software design goes this, but I've seen this waaay too many times to be unfazed by the assurances of prototypes not going external, of external prototypes not being immediately productized and of going through the initial conversations with new junior developers that start off with - "yeah we had to get that in quickly so...".
Some people will immediately jump on this as our Developer should have pushed back on the prototype, done it perfectly right, as per his specs and damn the torpedoes and Sales requests. This is not the answer. Developers need Sales like plants need water - no sales, no fancy new coding that combines HTML5, Azure, Lync and Dropbox into 1 whizbang application. Shutting down, becoming a Silo will never win the day.
No, in this case RDD really has 1 option, he has to accept that Sales needs something. He has to accept that time is finite. And he has to learn how to communicate with the Sales.
RSD: Why is the design taking so long?
RDD: I'm trying to understand what we are trying to do here. Maybe if we could have a call with some of our customers and walk through what we're thinking?
RSD: Yeah sure, I know some guys we'll set it up.
After the Customer meeting.
RSD: So I talked with the customer again and they are really pumped about the new features and are wondering when they can see something. They're eager to start using it.
RDD: Well based on everything we went over its going to take X amount of time to have something tangible and stable to show them.
RSD: Alright man, I'll leave you to it, this looks like we're headed in the right direction.
In general the conversation was a lot shorter (and it might actually have been longer with some more give and take), but the point here is the developer turned it around to the sales guy. Let's meet with the customer and talk to them about this. It is so early in the game, the Sales guy knows he has nothing to show so yeah all we can do is have a call. And at the end of it all the developer gave the Sales guy something which he so desperately needs - a possible lead, a possible upgrade, an increased warranty renewal - something that removed the unknown worry that was in their mind, increased the pipeline and could lead to some more sales. Now they have some assurance that the feature will be well-received, they have a potential lead and the light at the end of the release looks a whole lot brighter. You on the other hand, have just bought yourself some time to get buy-in from Sales to figure out the rest of your dilemmas and do the product right, without working on prototypes (maybe you will, but they will be evolutionary) and customer support nightmarish hacks that might make it into your suite.
Developers are always concerned with the design of the product, Sales are always worried about the conversion of that design into features which earn sales. Both sides are trying to eliminate the unknown to make their jobs a little bit easier.
The Architecture can't do that
This my friends is the Kiss of Death in software development. Want a surefire way to suck the air out of the room in seconds? Utter this line at your next feature review meeting. I love watching the room - scanning from developers to product managers to dev managers to sales to anyone else in the room - they are all looking at each other waiting for someone to jump in and offer some kind of an olive branch to let them breathe again. In the worst case, Sales starts to blame PM who starts to blame the Dev Manager who, if they are having one of those horrible days and is completely ignorant of the software suite, might look to the developer for answers.
The problem here is that it's the not the architecture of the product that can't implement the new feature(s). Of course it can, its software, you have IDEs, you built it, you can change it. Maybe you built it against some crazy convuluted design pattern that only Sara and her sister have full working knowledge of and they just bailed on the company and you really don't have a grasp on how it works or maybe its that the feature is so new that what you currently have in your software suite is completely irrelevant to solving the problem at hand?
These are not the faults of software architecture.
I've seen the look a developer has when he mumbles this statement for the first time, I've BEEN that developer who mumbles that statement for the first time. It's not a deer in the headlights look, it's a look of resignment where the developer starts to calculate all the different possibilities of what is being asked in the feature and they are evaluating it against what the system has and then factoring in how much time they have (there is a calculation here somewhere) and then it hits them - I can't give you what you want, when you want it without creating some steaming pile of dung that will do this and only this and become the bane of our existence for now and ever more. And the architecture takes the rap because it cannot quickly absorb the new features as fast as we thought it could, Widget A does not plug gracefully into the framework, instead it kludges in and requires a little finesse. Is this all bad, no not entirely, if this was the complete focus of your application/framework then yes this would be a bad thing, but in this case it is not you (as the developer) are trying to build a feature for a product for your company.
In the end, the problem is the delivery model.
No matter the role you play in feature delivery of a software product, when you hear someone mumble this answer your first thought needs to be to stop what you are doing and get to the bottom of the real issue (DANGER WILL ROBINSON! DANGER WILL ROBINSON). What really is the problem? Did we cut corners on the last release and now we are paying for it? We can fix that. Have we pushed out critical bugs that need to get fixed before we think about this? Are the expectations too heavy in too tight a timeframe? These are all questions that have nothing to do with the architecture and everything to do the management of the software.
When you dig into the reasons behind "The Architecture can't do that", it rarely ends up being the actual architecture but rather something else altogether that you never would have thought to be the issue in the first place.
Transformers 2: Revenge of the Bad Software Release
You'd have to be under a rock to know that the latest Transformers movie was just released 2 weeks ago and has made a ton of money to date (before being smashed by Harry Potter last weekend). At around the same time, some of the actors, writers and directors part of TF2 have all been panning it as a horrible film - it sucked, we knew it when we were making it, but we did it anyway, etc. But at the time, none of this criticism was out there and that movie went on to make a ton of cash (mainly because we thought it would rival the first one and improve on some missed points - yeah I'm a huge Transformers fan).
So here's my question, if everyone working on the movie thought it was bad, why release it?
Take the above scenario and apply it to any software release you are working on - your last release has a ton of bugs and loads of incomplete features, if it was your money you would have never bought it. What? You did a release that you are now panning AND you are doing this after I (your faithful customer) put down my money to purchase said software (which we all know software costs a lot more than a movie ticket). Taking that kind of response in our field is quite the kick in the gut to your customer base and will woefully hurt the trust account you have established with your customer - "Why should I believe you now?", "Can you really tell me that this is the piece of software that it going to make me happy?"
Time, resources and market demand are always going to be the key drivers pushing you to releasing early to get your product out the door - build that buzz, get that first sale, get feedback on that new feature, deliver on a customer promise - it all has a purpose and you will never release a piece of software that does not have something missing and does not have bugs in it. But the one thing you must, at all costs avoid doing is shipping a piece of software that you are not proud of. If you do not believe that the work you and your team has done is the best to your and their abilities, then it shouldn't be released, if you want your customers to believe in you, and remember the only they are going to be able to do that is through your software, then you better believe in what you are pushing out the door. Otherwise you're going to have a "Revenge of the Fallen Customer" on your hands where your own team criticizes it, your customers don't like it enough to not come back and renew their warranties and in your next release you're desperately trying to bring them back saying that is the what is should have been.
The clearest case of this happening in our industry was the release of Windows Vista and later Windows 7, critically panned since Day 1 Vista was a black eye to Microsoft, I don't know the numbers, but I definitely know a lot of work was done to win customers back with Windows 7 and there have been many a report of Win7 being what Vista should have been when it first went Beta before being released.