Birds are not narrow Animals - Mobiles are not narrow Desktops

Continuing through Vayikra; the weekly Torah reading:

There are 3 categories of sacrifices: Animals, Birds and Flour - each with its own method for sacrificing. 

E.g.: An animal is slaughtered the same way it's slaughtered for your kosher butcher, whereas a bird being sacrificed is slaughtered in a way that would make it unkosher for regular consumption. A flour offering is not slaughtered - that step is skipped.

When preparing a Technical Spec, one cannot simply treat the Mobile Phones as a narrow-screen desktop. That creates ridiculous and cumbersome interfaces.

A mobile User Interface must be designed specifically for a mobile device.

I recently used an interface that worked very nicely on a desktop - with the top left-hand side being your profile and dashboard - very convenient. But on a mobile the top of the screen was always your profile - and you had to scroll down to get any work done. 

That's what happens when you treat a mobile device as a narrow desktop.

And then you have the tablets - they cannot be ignored.

On a practical note, use a service like BrowserStack to see how your product looks on various devices and various browsers on those devices.

Prototype pitfalls

In software, a prototype seems to work like the finished product. In reality it's usually a pretty face (GUI) with minimal functionality.


If you actually try use the prototype you will discover that it only works for a limited set of actions, if at all.


My first introduction to a prototype was in the mid-1990's. My good friend Jack Kustanowitz arrived at Kivun (of Dagesh fame) as a summer intern. 


Netscape had just released the first Web Browser - and all you could do was browse. Maybe it also had a back button that went to the previous page.


Using Visual Basic, Jack created a prototype of WebTamer; everything your browser needed. Functionality like "History", "Off line browsing" and "Bookmarks".


And it seemed to work! Making a product out of it should be trivial, Project Management was assured. (These were the same non-techie Project Managers from yesterday.)


Suffice it to say that the road from Prototype to Release was long and painful, since the prototype was mainly a GUI; a pretty face, and Jack-the-wiz-kid was back in college.


Prototypes of the graphical interface are easy to create, very impressive and very misleading to Project Management - and Management in general. It's hard to see why a product which looks ready-to-use will need months of development before it can be shipped.


Sometimes a prototype is used as a technical proof-of-concept. Being unsure of the capabilities and limits of certain technologies, a team will implement some functionality with technology they have never used before. Usually some new emerging technology. 


They can then measure:

• How long did it take? Does this seems like a faster way to implement features?
• How stable is it? If we stress the application does it crash or slow down?
• How fast is it? If they implemented existing functionality, they can benchmark it to see if it's faster or slower than the existing implementation.

In this type of prototype, the important functionality will be there, but the GUI may be missing. 

Can the prototype code be used in the end product? Sometimes; often it cannot as the prototype will have been done without a technical design;  that crucial design stage that ensures that multiple programmers can safely and efficiently work on the same code.

What a Project Manager needs to realize is that prototypes - both types -  are not an indication of a finished product, no matter how good the demo looks or functions.

The connection between a prototype and the end product is often similar to the connection between an ad and the actual product, or the trailer of a movie and the actual movie. You've been shown the highlights; the devil is in the details.

Lessons learned:

Having a "working prototype" will not in any way shrink the schedule. "It's almost ready" is not true.

A prototype does not absolve the Project Manager from creating a fully blow functional specification document. Assume all the functionality is missing. What you see in not what you will get.

To be wise or to be right?

Yesterday I was watching a group of kids trying to define an ad-hoc game. They had about 15 minutes of play-time at their disposal.

Most of the kids just wanted to play and make up the minor details as the game went along.


There was one girl who was strong willed and was insisting and defining every possible rule - and she had a strong opinion as to what those rules should be.


Result: They spent the entire 15 minutes defining rules. Not all of them; some of them left earlier in disgust and went to play.


There's a delicate balance between a fully completed  spec and a perfect one.


This is one of those tough calls that a Project Manager has to make. The spec most cover everything. Or must it?


My father tells the story of how the programs in his time - coded on punch-cards (!!!) were able to handle leap years - including the exceptional ones - like the turn of the century. Their systems were Y2K-proof.


After all, they had no idea that the world would progress past punch cards - so the date formula was written for posterity.


At the time it was probably the best decision: the date formula is used all the time and adding an extra condition in the code was not a big deal.


After a spec is written, there is a spec-review meeting - where all those who will be involved in the implementation and testing should be invited; attendance is conditional on having first read the spec.


At those meetings there will be some heated debates about missing features or how to implement seemingly trivial functions.


The key is to listen carefully to what is not being said. Very often one of the vocal (loud or insistent) reviewers of a spec has a hidden agenda: e.g. a pet concept or implementation that they want to use - or learn how to use.


Or a skill set they want to use. Or a fear of the unknown. Sometimes it may be a (self declared) expert who (erroneously) thinks she needs to have original input to everything, otherwise she'll lose her job.


Sometimes it is a simple case of "Perfection is the enemy of Completion".


A trick that I learned for all meetings that get side-tracked or are taking too long: After 30 - 45 seconds simply interrupt the interruption and say "let's take that off-line".


Write it down and make sure to follow up (usually with an email, to as few people as possible) - otherwise they will stop letting you use that line. 


Often the follow-up email will be the end of the story. After all, the proposed concept was only to gain attention during the meeting and not to actually try improve the spec.


Sometimes the ideas being suggested are correct - but will kill the scope of the project. Be realistic about the life expectancy of the project. 


besides, it's often best to ship a feature-free product ASAP and then - if it's a success - to release frequent updates.


It's better to get requests for more features rather then complaints about poorly implemented features.




- Danny Schoemann

RetroSpec: The quick long way

RetroSpec: The act of writing the spec after the code has been written.

For various reasons, sometimes it makes sense to first write the code and only afterwards to write the spec. 

For example: You may not be sure what is technically possible, you hope for at least some minimal functionality, but discover that it's trivial to implement a fully-blown feature.

Sometimes it doesn't make sense, but it simply happens; a quick fix or tweak turns into a feature. This could be the result of a programmer having a sleepless night and dedicating it to the cause, or a team having an internal competition.

Or it may simply be a case of feature-creep.

If it's already coded, why the spec?

If nothing else, QA needs to be know what to test, and without a spec that cannot know what is broken or purposely missing.

If you keep documentation up-to-date, then you will need a spec so that the technical writers have a starting point.

But the most important reason to RetroSpec is to enable a spec review. Experienced Project Managers are adept at discovering the corner-cases, but can only do so if there is a spec to review.

If need be, the Project Manager should write a spec, simply in order to ensure that the corner cases are covered.

In a future post we will give examples of typical corner cases, and how to find them.

- Danny Schoemann