Shipping

It’s inspirational, to hear project managers telling the team to try harder and do better……That the software is not yet good enough….….”It should be like this”…”It should be like that” . It works to undermine excuses for poor or shabby work. And, most importantly, it helps team members develop the courage to stand up for these values in stressful situations. Under pressure, the temptation to cut corners, or to hand off shoddy work to another department(QA or Support) is overwhelming. It requires courage to stand up and say: “this work is simply not good enough. Sure, we could get away with it, but that’s not how we work.” Good PM’s work hard to create an environment where this courage thrives.

On the other hand, there are many stories of companies achieving a breakthrough by shipping something that was only “good enough.” One such ‘gist’(guess it was Weiss-Malik that mentioned it….not very sure) , tells of the launch of Google Maps. The team was demoing their AJAX-powered map solution, the first of its kind, to senior management at Google. They were impressed, even though the team considered it still an early prototype. Larry and Sergey, so the ‘gist’ goes, simply said: “it is already good enough. Ship it.” The team complied, despite their reservations and fear. And the rest is history: Google Maps was a huge success (though some of my colleagues think Nokia maps rule  ). This success was aided by the fact that it did just one thing extremely well – its lack of extra features emphasized its differentiation. Shipping sooner highlighted this difference, and it took competitors a long time to catch up.

So when exactly is it good enough to ship?? When the product is ‘very finished’ or work in progress?

Most of us (in software development) intuitively have a “split the difference” attitude when faced with recurring difficult choices. Everyone naturally falls along an array of entity, from “ship anything soonest” to “always build it right, no matter what it takes.”

I want to explore the idea of releasing “crap”: that our product is of such low quality that we will release it, customers will hate it, and we’ll have accomplished nothing but alienating them. But notice how many forecasts are cooked into this supposedly simple scenario…..we believe we have already solved the distribution problem for our product (or else how could customers try it?). We already know who to distribute the product to (or else why would we care what they think?). Naturally, we already know the standard of quality that they(users) will use to judge our product. And, of course, we already know that they will care enough to be offended and they will most likely tell their friends how unhappy they are…..(and we know that’s bad for business when it happens) In fact, we know so much that we already know what they will care enough about (namely, the product’s quality – as opposed to, missing features).

It is entirely possible that we can ship “crap” and have one of the aforementioned facts fail to materialize. In fact, that is one of the best possible outcomes, because it will force us to learn something. What if customers actually like the “crap” product? Or what if we can’t get any of them to even try it? Or what if the features they demand we build are different from the ones we were planning to build? In those cases, we can’t help but learn a great deal. Remember, the minimum in minimum viable product does not mean that you should ship just anything at the nearest possible date. It means to ship as soon as it is possible to learn what you need to learn…..depending on what you want to learn.

So what about the question of whether ‘ready as in ready’ or work in progress? What’s needed, I think and like david hansson(37 signals) said, just build something awesome, something you yourself would love to use and ship it while staying focused .Talking about being focused, following the idea with rigor while continuously improving, there is no such thing as good enough. Our pursuit of learning is ongoing and our commitment is absolute. But when it comes to the specific of a product release, business plan, or marketing launch, all that matters is: do we have a strong forecast that will enable us to learn? If so, execute, iterate, and learn. We don’t need the best possible forecast. We don’t need the best possible plan. We need to get through the build-measure-learn feedback loop (sometimes it enters an endless loop…at least facebook is a good testimony) with maximum speed.

Moral of the story, good enough won’t happen as fast as we expect (in my opinion)….get excited, build(……try to stay off the crappy path though), deploy ,patch, iterate on and on….you feel differently? Please, leave a comment or send a message and let’s discuss.

Follow me on twitter for short bursts 140 xters or less.

“Hacking”

On my way home last night, my mind went to the word “Hack” …. the way it is and the way we look at it…..

Hacking is most commonly associated with computers, and people who break into or otherwise subvert computer systems are often called hackers. Although this terminology is occasionally disputed, I think it is essentially correct…….these hackers are discovering the actual rules of the computer systems (e.g buffer overflows), and using them to circumvent the intended rules of the system. The same is true of the hackers who break DRM or other systems of control.

Clunking out clever code is also described as hacking. In this case the hacker is violating the rules of how we expect software to be written. If there’s a project that should take months to write, and someone manages to hack it out in a single evening, that’s a small miracle, and a major hack. If the result is simple and beautiful because the hacker discovered a better solution, we may describe the hack as “elegant” or “brilliant”. If the result is complex and hard to understand (perhaps it violates layers of abstraction), then we will call it an “ugly hack”.

Important new businesses are usually some kind of hack. The established business thinks they understand the systems and have setup rules to guard their profits and prevent real competition. New business must find a gap in the rules…..something that the established powers either don’t see, or don’t perceive as important (I believe we all know the story of Google and search).

The entire process of building a business and having other people and computers do the work for you is a big hack. Nobody ever created a billion money business through direct physical labour……it requires some major shortcuts to create that much wealth….and by  definition those shortcuts were mostly invisible  to others.

Not everyone has the hacker mindset, but wherever and whenever there were people, there was someone starring into the system, searching for the truth. Some of those people were content to simply find a truth, but others used their discoveries to hack the system, to transform the world. These are people that have made a difference in their fields…beliefs and religion….and they did it by hacking the prior systems.(consider the challenge of establishing a successful business…..the established businesses “Sharks” won’t give up easily)…..now to the moral of the story.

To discover great hacks, we must always be searching for the true nature of our reality, while acknowledging that we do not possess the truth, and never will. Hacking is much bigger and more important than clever bits of code in computer…..its how we create the future.

……a lot of jargon right???? …….follow me Twitter for short bursts…. 140 characters or less…

Demystifying HTML5…..

Over the past few months, the web has been agog about the new buzz word…html 5. Some say it’s the gears killer while some say it will send flash player (and other RIA techs …silverlight, javafx etc) packing from our browsers. All these raise one question, what is HTML 5?
HTML 5 is a specification for how the web’s core language, HTML, should be formatted and utilized to deliver text, images, multimedia, web apps and every other thing you see in your browser. It is a set of core standards that web developers need to worry about. In short, it’s a major revision to how the web is put together. Not every web site will use it, but those that will do will have better support across modern desktop and mobile browsers.
Most of the changes in HTML5 have already been made public while the HTML5 working group is till busy at work, we are now to see new tags like.., , , etc while the end has come for tags like , etc. We will now have features like

Offline storage: You can see them like “Smart Cookies” but with much more space to store both one-time data and persistent app databases, which is more like what Google gears is offering at the moment.

Canvas Drawing: Web applications will now be able to make use of interactive charts and graphs, game components and whatever the developer wants can be drawn directly by programming code and user interaction without using Flash or any of the popular RIA technology.

Video and audio streaming: Though it’s still majorly “work in progress” … like we are all aware , YouTube released another version of their site last week…which uses pure html5 to play videos instead of the known flash technology(though you will need html5 compatible browsers to watch the videos). You can find it at http://www.youtube.com/html5

Geolocation: Just what it sounds like, but not limited to a single provider’s API or browser tool. HTML5 can find your location and use it to tailor things like search results, tag your twitter updates, and more. This feature will definitely come in handy in the mobile market.
Without boring you out with all the known features of HTML5, it’s fair to say that HTML5 is aimed at making it easier to build wikis, drag-and-drop tools, discussion boards, real-time chat (Like we have in Google wave) and other modern web elements into an application, and have them work the same across browsers (while we keep praying that the IE team will quickly join the W3C HTML5 working group).

Nexus One…..

There will be a lot of personal views and opinions on the look, feel and features of the Nexus One, I will say it’s the battle for the web. iPhone Vs Android.

The key to the turning point is not how slick the Google phone is – even though (according to reports) it’s thin, fast, bright, and beautiful, with amazing sensor-based capabilities including noise-canceling headphones, automated brightness adjustment based on external light levels, voice activated search, navigation and data-entry. Nor is it the fact that you can buy unlocked phones directly from Google. The real turning point is Google’s commitment to making the Nexus One a web-native device. According to Google’s VP of product management during their press conference, a nexus is a place where multiple world’s meet.”The Nexus One is where the phone meets the web”. It’s a connected device in a way that is more fundamental than any previous.

While Google has a lot to work on to be able to catch up with Apple (majorly with the app store), I think the all round simplicity of the Nexus One and the completeness of the cloud integration is a major advantage. What we see then is a collision of paradigms, perhaps as profound as the transition between the character-based era of computing and the GUI based era of the Mac and Windows. We’re moving from the era in which the device is primary and the web is an add-on, to the era in which a device and its applications are fundamentally dependent on the internet operating systems that provides location, speech recognition and other fundamental data services. I know more manufacturers  are going to tow this line…..welcome to the new world :).

The value of an idea……

How much is an idea worth? Many normal people assume that ideas are valuable, and that if only they could think of one, they might be able to sell it for millions of money. On the other hand, many engineers, VCs, and successful entrepreneurs claim that ideas are worthless. Paul Graham provides a sort of “proof” that ideas are worthless:
People in the “ideas are worthless” camp usually claim that it’s all about execution — they have plenty of great ideas that just need great teams to execute on them.

I have ideas all of the time, many more than I have time for, and so I tend towards the “ideas are worthless” camp. However, there’s a nagging inconsistency — something isn’t quite right.
I’ll assert that market is the most important factor in a startup’s success or failure.

The product doesn’t need to be great; it just has to basically work. And, the market doesn’t care how good the team is, as long as the team can produce that viable product.
Conversely, in a terrible market, you can have the best product in the world and an absolutely killer team, and it doesn’t matter — you’re going to fail!!!!

In other words, you just need to build the right product.  A mediocre team building the right product will succeed and a brilliant team building the wrong product will fail.

Isn’t that a little bit like saying that having the right idea DOES matter? And if ideas are so plentiful, then why do we see great teams executing perfectly on bad ideas?

I’ve thought about this for a bit and realized that both camps (“ideas are valuable” and “ideas are worthless”) are wrong, at least when stated so simply.

Imagine that products are mountains. To build a product, you will need to climb that mountain. Some mountains have a big pot of gold at the top, and some do not. In order to make money, you will need to pick the right mountain and then successfully climb to the top and gather up the gold. You can fail by choosing a mountain that has little or no gold at the top, or by dying on the way up.

Taking this metaphor a little further, there are also multiple paths up the mountain. According to Wikipedia, Mount Everest has fifteen recognized routes to the top. Some routes are easier than others.

Successfully executing a trip to the top of the mountain requires a certain level of technical ability — how much will depend on the mountain and route. It also requires good judgment in order to choose the right route, or to change course when you realize that the current path isn’t working out.

Judgment isn’t talked about as much as execution, but it’s obviously very important. A technically brilliant team, upon encountering a sheer cliff, may excitedly think to themselves, “this is the perfect opportunity to use Erlang!” (or some other fancy tech — Erlang is just a funny example) A team with better judgment would notice that there’s an easier route that goes around the other side.

Judgment also plays a critical role in choosing which mountain to climb. Our landscape of product-mountains has millions of different mountains, many of which have never been climbed. Other mountains have been attempted in the past, but the team froze on the way up, or there was no gold when they got to the top.

There are also people wandering around in the flat lands near the mountains. Many of these people have ideas about which mountains have gold at the top, and some of them have even drawn crude maps showing what they believe to be an easy route to the top. Inevitably, they try to sell their ideas and maps to the mountain climbers, but the climbers just brush them off and say that their ideas and plans are worthless.

Eventually, a team of climbers will discover a huge cache of gold on one of the mountains. Naturally, the people who were hanging around at the base trying to sell their ideas and plans will say, “I had that idea first! They stole my idea! I knew there was gold at the top of the mountain!”

And it’s true that they had the idea, as did many other people. Ideas are plentiful. The problem is that most ideas are bad — either there’s no gold at the top of the mountain, or the ascent is too difficult with today’s technology. What’s valuable is the judgment to know which mountains have the gold, and the team that can get to it.

For me, the year has been tough having to change a lot of things, from my favorite technology to the city I live in…but in all it has been a successful one.  Wish you all a merry xmas and a wonderful new year ahead.

Follow me on twitter — http://www.twitter.com/sogoojo

Web Accessibility

As I write this, am just recovering from an appendix operation. The symptoms were diagnosed in less than an hour and before I could say geek…I was in the operating room. Thank God I survived it and my love goes out to everyone that came to my rescue. Thanks and I love you all.

Complacency and disbelief are phases I go through when I think about web accessibility.

Working in a software development firm, where our day to day activity involves building applications and making old ones better; we spend time making sure our sites are accessible, that our applications degrade gracefully, that our JavaScript doesn’t create barriers when using our applications. We do this ad-hoc, without even a firm sense whether our target ultimately requires it. And for no reason other than its our job. In all we do, we make sure best practice is right at the top of our priorities.

Most developers out there don’t necessarily agree, to them its all about getting an application off the shelf and kicking accessibility to the curb. We should make an effort to create accessible content, because its’s part of our job. And frankly, it doesn’t take much effort.

Nobody’s expecting perfection. Nobody in their right mind ascends to the notion that everyone is equal, or that life is fair. People aren’t equal, and life isn’t fair. But that makes it even more important that we attempt to redress imbalances when we encounter them.

What we do is not rocket science — I won’t say it’s easy, but it’s not spectacularly difficult either. HTML was designed with accessibility in mind, and it provides the hooks and meta-information to make content more accessible: alt text for images; caption, summary and headers for tables; good heading structure; semantic use of paragraphs, lists and other structural markup. Used properly, our tools will do the job. Used badly, they create barriers.

And technology is the one area of human endeavour where that simply isn’t acceptable. Technology is not like the physical world, where there are good, tangible reasons why some things can never be accessible. A person who’s blind will never win the 100 meter dash; someone in a wheelchair will never be able to climb Mount Everest. Technology is not like the physical world — technology can take any shape. Technology is our slave, and we can make it do what we want.

If we call ourselves professionals, we owe it to our clients, their clients, and ourselves, to do our job properly. A chef must care about health, a builder must care about safety, and we must care about accessibility.

For starters let your next application be accessible to screen readers and work fine on mobile platforms…. It’s the end of a big year for us, and we’ve got a lot to celebrate … but of course there’s also plenty to look forward to in the year ahead! ……MERRY CHRISTMAS!!!!!

Developer’s Personal projects

It’s interesting to note that many web developers go through a similar process over the course of their careers. One of those rights of passage is the building of a particular application type. Cutting your teeth on building a larger scale application (at least, larger than a contact form that emails somebody and larger than hacking up an install of WordPress) seems to inevitably involve developing a custom application, either as a personal project or as some client deliverable.

Most importantly, I believe that a tried and true web developer should go through this process to understand the pain points of developing larger applications. There are three different types of applications that are certainly great exercises using any language of choice:

  1. The forum
  2. The blogging engine
  3. The content management system

Each of these often has a number of concerns that are always pertinent — such as user experience design and workflow, authentication, spam handling, email management and certainly database design.

The Forum

Over the months, I built a small forum which could definitely pass for a forum anyway (simple and does its work). Forums can be simple or they can be complex. Software like vBulletin or phpBB have grown to include a massive number of features, most of which are overkill for the average forum. There are certainly some critical design decisions that have to be made such as threaded or inline thread replies, thread notification, thread stickies, and user registration.

The Blogging Engine

Forums are probably the least popular application type these days as most people seem to prefer building a blog engine instead—the similarities of which are interesting. Both have a main topic with the ability for people to respond. The main differences are in who’s allowed to post (everybody vs admin) and who’s allowed to reply (registered vs anonymous).

Over the last few years, the blogging engine has certainly become one of those things a web developer just does—usually as a result of outgrowing whatever engine they were using before.

Blogging engines can be much more complex than a forum, though, including trackbacks and RSS generation. (Not to say that RSS couldn’t be in a forum; in fact, it probably should. It’s just more prevalent in blogging.)

The Content Management System

The pinnacle project of a web application developer is the custom content management system. Born from the frustrations of trying to wield open source or commercial applications, it seems to be every developer’s duty to try and build a custom CMS though it could take a very long time to build one from scratch without using any framework. How do you manage different object types? Templating, authentication, workflow, internationalization and localization are just a few of the issues you have to contend with in building a CMS. Do you go simple or do you go complex? How does the average user, with little web experience, find their way around the application? How easy is will it be for another developer to build a module or plugin for your CMS.

Building a custom CMS is a fantastic excercise on so many levels — well beyond what you run into with a blog or forum. Above and beyond forum design and blog design, CMS design really requires you to step outside of yourself and understand what the pain points are and how to solve them. This might also explain why most of them seem to suck and why developers around the globe continue to feel the need to reinvent the wheel (like my chief will say)but the fact remains that at a point in time when u really have the time…reinventing the bumpy wheel is juts ok.

But it’s also the avenue with seemingly endless possibilities. Is it hosted, is it custom, is it for the designer, is it for enterprises, and so on and so forth.

Any others?

What type of project do you feel is a great way to grow as a developer? As always, comments are open and my mind remains open as well….cheers.

PS. If u are in Nigeria and u feel we need to organize some sort of a developers conference like we have in other parts of the world..pls get in touch and let’s do something…..

Oluwasogo.

Follow

Get every new post delivered to your Inbox.