The New User Interface

It’s not unusual for IT to slide back and forth between extremes–thin client to fat client, back to thin client and back, etc. One of those pendulums has been UI programming. Back in the early 90’s user interface programming was either CHUI or roll your own custom GUI. Standardization was not common until Windows 3.1. In the years since standardized GUI components have contributed to massive productivity gains. But standardization of the UI has largely played out. Today the new frontier is again customized user interfaces. But a lot has changed—graphics hardware is far more powerful and enabling technologies like “WPF” and Seadragon http://livelabs.com/seadragon/ abstract away the complexity.

Right now it’s mostly people playing with photographs, but I see an emerging wave of more general applications. For the last ten years web technology has been the big thing. (Supplanting programming languages which was the big thing of the 1990’s) In the next 10 years UI technology has a good chance of becoming the dominant trend-setter.

 

Note on this Post:

Joel Arthur Baker in Paradigms: The Business of Discovering the Future discusses how shifts between patterns of thought (paradigms) create significant opportunities. Software development has historically been a pace where paradigm shifts are common–but today it seems we are seeing more than ever.  This post is one of a series discussing some of these paradigm shifts.

REST for Corporate IT

REST is old news for web based companies, but it’s penetration into corporate IT is just beginning. SOAP has three big advantages for the corporate developer—familiarity, tool set support and ease in handling large input sets. Want to pass a 3,000 character SQL statement to a web server? SOAP swallows it up without blinking.

The consistency of SOAP however is its undoing.  Whether it’s a huge, complex sets of “simple” data or a tiny status query a SOAP service requires essentially the same infrastructure.  REST tends to scale. A simple REST service is simple.  That is a pretty compelling advantage.  It’s convenient to pop-up a web browser and see what’s going on—try that with SOAP.

To the purist out there—sorry, I don’t think the HTTP methods (GET, POST, PUT, DELETE) are going to catch on. Using anything but GET kills the “web browser as development tool” advantage and it’s just too easy to define URLs with an embedded “get” or “delete”. But if you’re willing to let that slide REST will have a nice future in Corporate IT.

 

Note on this Post:

Joel Arthur Baker in Paradigms: The Business of Discovering the Future discusses how shifts between patterns of thought (paradigms) create significant opportunities. Software development has historically been a pace where paradigm shifts are common–but today it seems we are seeing more than ever.  This post is one of a series discussing some of these paradigm shifts.

The Affect of Minimum Wage on the Recession

A few days ago while standing in the Wal-Mart line the cashier asked me, “Hey, didnt you go to Southern Adventist University?” Ends up we were classmates about 9 years ago. He told me after graduation he’d spent most of the last decade managing a construction firm until it went under. Thus the entry level job at Wal-Mart.

I don’t think this is an isolated incident. As industries shake up highly qualified and motivated people end up jobless. Smart employers snap them up in jobs that normally never hope to attract such talent. The people that normally occupy those jobs shift lower into less desirable jobs, or no job at all.

Established companies aren’t the only ones shopping for unemployed talent Entrepreneurs also thrive on the low cost labor. Back in the 1930’s my grandpa spent a summer working in an entrepreneurial startup–an iron mine. The project failed and he walked away with only food and board. (And some great stories for his grand kids)

Low wage employment isn’t optimal, but at least it keeps money flowing in the economy preventing further disruption. As conditions improve (due in part to some of these new businesses succeeding) the demand for labor is slowly restored. The competition for employees pushes wages back up to their pre-recessionary rates.

But can this happen today? The Federally mandated $6.55 an hour minimum wage means employers must risk at least that much on an employee. For most business that’s not much of a barrier, but for some new business putting out that much cash may simply be too much risk. Will people at the bottom of the economic ladder go unemployed instead? Will this extend the recession? The evidence suggests the answer to both questions is yes.

 

---

*I’d like to give credit to the Let’s Talk Money show on Chattanooga’s WGOW whose discussion on whether the minimum wage increase caused the recession inspired me to write this article.

The 6th Grade Financial Crisis

When one of my software engineer friends was in 6th grade his teacher decided it would be a good learning experience for the kids if she created a mock economy. She had no idea how popular and profound the experiment would be.

Kids could now trade for durable goods (lunch components, spit wad shooters) without immediately needing an equally valuable item to trade back as required in the barter system. The introduction of currency was a massive success and the classroom economy blossomed.

 

Even as a kid my friend was well known for his analytical skills so was assigned the job of class banker. He turned out to be a very good banker. In adult society, bankers play an important role loaning money to people with earning potential and a need to buy. For example, buying a car to drive to your first job*, or a house to raise a family. In short, a healthy banking environment is a lubricant of possitive economic activity.

 

I suppose the teacher intended that the classroom banker would loan out small amounts of money to kids who just had to have that cookie for lunch. However, it didn’t work out quite that way. For each loan my friend gave he received a 10% commission. It didn’t take him long to realize that the more transactions he as involved in the richer he’d be. So when fellow students wanted to buy goods he was quick to market his services.

 

The teacher’s photocopy machine offered an endless supply of cash so his bank rapidly pushed tens of thousands of dollars into the classroom economy. The flood of cash rapidly pushed up prices. Spit-wad shooters started selling for thousands of dollars each. The rising prices encouraged further borrowing. The bank had positioned itself at the very center of the economy. Much of the classroom spun deeply into debt–except for the banker who happily kept amassing his 10% cut. The banking industry was booming.**

 

Part of the classroom however boycotted the raising inflation. Literally–”boy”cott. In typical grade school fashion the girls didn’t believe in doing business with the boys. They happily traded with each other in tens and occasionally hundreds of dollars. They didn’t have a banker raking 10% off the top of every major transaction, nor did they need one. The isolated girls economy was breached only once when a girl let one of the boys buy part of her lunch for $2,000—instantly re-aligning the value of cash in the girl’s economy.

 

I would have liked to have known what eventually would have happened to the mock economy, but unfortunately about then the teacher decided to bring it to a close and the classroom reverted to the barter system once again.

 

---

*After that pay cash. 
** The expansion of the US banking industry during the mortgage boom was a very bad sign. The controlled collapse of the financial sector we’re seeing today is hopefully the start of a return to sustainable banking.

$163.29 for Auto, $4,572.18 for Finance

It’s frustrating to see new article after news article throwing out terms like “25 billion dollars” with no further explanation. As if any of us except Warren Buffet really understand a billion dollars. On a visit to Chicago I saw a million dollars in a museum display at the Chicago Fed—it is a huge amount of money—about a 6 food cube of solidly packed bills. I can’t even imagine a billion dollars.

You’ve got to break billions into numbers mortals can understand. I like dividing by population. In July, the US had an estimated population of 303,824,640*. Take the proposed auto-bailout of $25,000,000,000. Divided across everyone in the US that represents $82.28. That’s a number I can wrap my mind around.

If we exclude the babies, small children, students, disabled and retirees and look at just the labor force (which includes the temporarily unemployed) there are approximately 153,100,000* workers. The $25B auto bailout comes to $163.29 per working American. The $700B financial bailout comes to $4,572.18 per working American.

* https://www.cia.gov/library/publications/the-world-factbook/print/us.html

The Requirements Myth

Years ago I first heard this myth and it lodged itself deeply in my mind. It seems so true that it’s taken years to shed myself of it. The myth: Never start designing and certainly NEVER start writing code until the requirements are defined.

It implied that requirements make a foundation of solid rock on which to build grand edifices of code. Unfortunately, none of it is true. As a foundation requirements are no more stable than the shifting sands of North Carolina’s Outter Banks. Initially sketchy and ill defined with work requirements can grow into something akin to Mr. Obama’s political platform—all inclusive and contradictory. In school we were warned about some of this and armed with a technique to defuse it—the use case. Supposedly, if you define all user interactions the full scope of a system can be defined before one line of code is written. The problem: real users don’t have a clue about computer systems. Imagining interaction with a computer system requires a technical understanding of the evolving abilities and limitations of computer systems. Domain experts rarely have that knowledge.*

Domain experts don’t talk computer. They talk in domain. Domain problems, processes, challenges, and trajectory of change (in the domain field). Successful systems start in the domain. That is the ground-zero of a software system.

Building on ground zero produces a curious side effect. By nature domain understanding does not lead to specification. Understanding suggests design. A very important part of design is limits. When design is allowed to bubble up from understanding it’s easy to put the limit of the design into places that are logical for the domain. In contrast to design, requirement definition is limitless. The requirements gathering process typically goes on until someone says “I think we’ve got enough now”. That arbitrary stopping point becomes a design limit and hobbles further system development.**

The solution is to write the requirements after the design is created so that the scope will be defined. If a design is new it’s often a good idea to write a little code to prove the design will work before investing in the requirements. I haven’t done a scientific survey to prove this, but my guess is that the design of almost every great new invention was created long before any sort of specification/requirement document was written—if there ever was one. It also seems that great designers are almost always people who have a deep understanding of the domain as well as being excellent technologists.

Now that I’ve trashed on requirements some of you are probably getting fired up in their defense. At least I hope so because a requirements documents is one of the most useful tools in the software engineer’s tool belt. One of the most important things Software Engineers can do is communicate proposed designs/changes with key stakeholders before heavy investments in development are made.

Requirements give stakeholders the chance to review changes and catch misunderstandings. It also gives them a chance to plan for their future. Changes in software systems are disruptive and giving stakeholders the tools to coordinate change is important. I don’t know of any tool that does this better than a requirements document.

In Summary:

1. Understand the domain

2. Define the design (rough draft)

3. Prove the design works (prototype/mock-up/stubbed out, etc)

4. Write requirements

5. Write code

6. (Iterate 1-5 as needed)

The Myth reversed: Never write requirements until you’ve designed your system and written some code.

---

 *I have found use cases to be somewhat useful for explaining existing systems to technical/managerial people, but it’s too clunky and abstract for much more.

**If the requirements first method is used for maintenance patches the problem of arbitrary design limits compounds.

Why I Support John McCain–A Geek’s Analysis

First, let’s knock out the junk that invarably clutters a campaign.

Things that Don’t Matter

The War–going into Iraq was a choice.  Getting out of the war is fairly straight forward.  1) establish security, 2) build up local government, 3) turn control over to the locals, 4) leave.  Right now we’re between #2 and #3.  It’s unlikely that McCain or Obama will be able to do anything to change those dynamics.  Expect both to talk differently, but ultimately do the same thing.

The Economy–the President has little influence on the economy.  Much of the economy is driven by fear/greed/global economic cycles that the U.S. government can do little about.  In the short term, much of what little the U.S. government can do is done through the Federal Reserve Board.  Members are appointed by the president, but in recent years the Fed has become largely a non-political institution.  (Former Fed Chairman Alan Greenspan served both Republican and Democratic Presidents)  I would be surprised if either Obama or McCain replace Mr. Bernanke. In the long term the President has some effect by influencing the legislative branch which does play a significant (long term) role by defining business law/oversight and controlling the US budget.  But at best the President is no more than a small minority shareholder in someone else’s show.

Moral Positions–our Federal government fragments power in such a way that any one branch of government can easily check the aspirations of any of the other branches. It makes our government maddeningly slow to act, but also prevents a president from imposing extreme positions–for example prohibiting abortion in the cases of rape and incest–on an disagreeing population. 

Issues that Would Matter if I had the Gift of Prophesy

Military vs. Domestic Spending:  The rhetoric indicates that after the Iraq withdraw Obama would invest the “peace dividend” in beefed up domestic/foreign aid spending. McCain would re-invest the savings in military.  Here’s where the gift of prophecy comes in–no one knows who is going to attack next. Historically large armies prevent expensive wars.  (That’s how Switzerland and Sweden stayed out of WWII)  Bin Laden’s Sept 11 attack is no exception–he’d been watching the US for years and had become convinced the US was a “paper tiger”. Is there another Bin Laden out there we need to intimidate?  Who knows.

Health Care: The system we have is a nightmare.  My typical medical bill comes with a 25% to 50% “network discount” because I have health insurance provided by my employer.  If I was part of the working poor I would get NO DISCOUNT.  (It’s against the law for health care providers to offer a cash discount, but are required by insurance companies to offer people with insurance major discounts)  In short the working poor not only don’t get help from insurance, they pay a total bill that’s 25% to 50% more than the combined bill paid by richer American’s and their health insurance companies.  Another example–if someone is born with a chronic medical condition they can be deemed “uninsurable” and can not purchase private health insurance.  In other forms of insurance the buyer has a choice–at least in part.  If I drive fast and dangerously I’d better be prepared to pay high auto insurance.  If I choose to live in a flood plain–I’d better buy flood insurance.  But if I choose to be born?  People who fall into that unfortunate category must either hold onto a job or pay the “poor tax” on the uninsured.  A fair nationwide plan is appealing.  However, considering the “success” of large government projects–Katrina, rebuilding Iraq, veteran’s health care, etc, I have little faith that the federal government has the capacity to successfully administer an effective and fair nationwide healthcare plan.  I would be overjoyed if the next president could accomplish as much as simply convincing Congress to create fair laws that even the playing field so that the uninsured are no longer paying more than the insured.

 

Finaly, why I Support McCain

Sarah Palin.  It’s not just Sarah, but what it says about McCain’s ability to build a diverse/quality executive team. 

1) She is a Governor–By picking Palin McCain emphasised that his own vast legislative experience needed to be augmented by someone with executive experience.  Obama’s selection of Biden is disappointing at best (suggests his limited legislative experience is not sufficient) and downright bad at worst.

2) She is a Woman–she epitomizes the values the feminist movement taught America. Her grit and determination are inspiring.

3) Efficiency–she’s one of the (very) few politicians that’s successfully taken on government corruption.  In an age where the dominant political strategy is to build coalitions of special interests her re-occurring theme is that the people’s money should be spent on projects the people want.  That’s refreshing.  (Her 80% approval rating is phenomenal)

Lastly–with the house/senate Democratic (and unlikely to change) I fear the loss of Gridlock.  Gridlock is good.  Gridlock makes people stop and think of creative solutions that satisfy not only their constituents, but their opponents constituents.  Gridlock favors America.  You won’t hear this from any candidate’s lips– but I’ll say it: Vote for gridlock!

Jeff Staddon is an independent voter who has voted for both Democratic and Republican candidates in the past.

Lessons from Custer’s Last Stand

On June 25, 1876 a distant relative of mine, Major General George A Custer, met his end leading 210 troopers into a disastrous aborted attack against a thousand or more Dakota (Sioux), Northern Cheyenne and Arapaho warriors. Today Custer is remembered most often as the butt of jokes and cartoons.

However, a twist of fate related his family to my family. To better understand our infamous kin my grandpa acquired a small collection of books by* and about Custer that I read as a kid. It became clear the popular story of “stupid idiot attacks huge Indian camp with tiny army” wasn’t accurate.

In 1876 Custer was one of America’s best frontier soldiers. Only 7 years before in a brilliant and nearly bloodless (thus nearly forgotten) campaign he had concluded an enormously successful posting in Kansas ending the Indian wars in that part of the plains. Going into his final battle there is good evidence that Custer believe he would repeat that success. And with good reason—he was an expert–he understood the tribes of the plains. The facts as he knew them:

1)Villages were small—the plains tribes engaged in hunting for survival and trade**. Small villages were more efficient.
2)Villages were highly mobile, but hard to defend. When attacked villagers typically fled.
3)If villagers spotted an enemy scout they would flee first and ask questions later. Thus reconnaissance/scouting was kept to a minimum.

As he approached the village he attacked according to this “truth”. He divided his command into three groups. One to attack from one side, one to attack from the other, the third to circle around and cut off fleeing villagers. Custer didn’t live long to appreciate his mistake. The “village” was actually a tribal gathering of about half a dozen villages who may have outnumbered his entire command two or three to one. His small bands were easily pinned down to be destroyed at will. The first attack was immediately beaten back. The second band of attackers was completely annihilated. The third group found no fleeing villagers and returned in time only to save the first group from annihilation. 

Application
What happened on the Little Bighorn in 1876 is nothing unusual. After a few years of success in any field it is natural to being to feel like an expert. The inquisitiveness of the junior employee disappears in the confidence of accomplishment. Experts understand the “truth”. But when that “truth” changes experts are often caught totally off guard. As a computer programmer I have to constantly guard against falling into my own “Last Stands”–technology changes, best methods change, problems change. The only solution is to keep open, growing and flexible.

---

*Custer was an excellent writer
**By this time the tribes were very dependent on non-indigenous technology—guns, ammunition and durable metal arrowheads.
Note: Photos from wikipedia. Top: Custer, Middle: Chief Gall, Bottom: Cheyenne village

The Right Answer: How to Talk to a User

A user calls a programmer and says, “We need a button on screen ______ to do _____.” What is the right answer?

a) Sure we can do that for you.
b) Wow that screen already has way too much stuff on it. Adding another button will make it way too busy.
c) That screen wasn’t designed for that. But you can do it by. . .
d) Hmmm. Help me understand the context a bit better and where this fits in. Sorry, I just do a better job coding if I understand the big picture. . .

Answer A sounds helpful, but it will result in patch after patch being applied haphazardly. Eventually this will break down the technical unity/cohesiveness of the system. In the end the system will be what the users requested, but probably not what they wanted. Answers B and C put the user on the defensive. Even if the argument is “successful” it may leave lingering resentment.

The right answer is D. It opens that critical two-way communication channel between programmer and user. Over the years I’ve noticed that the most effective programmers understand the frustrations of the user’s world and write their programs to solve those problems (not add to them). The flip-side is true for users. The most effective users understand the applications/technology they use.

Neither programmers nor users automatically know such things—they must teach each other. One of the best times to exchange that knowledge is when a request is being made. Always start by asking the user about their world—people like to talk about what they do. And what they do is the basis for your application—and for their change request.

Once they’ve described their processes, start drawing connections between those processes and the application. You’ll probably realize with a shock that the application doesn’t even come close to matching the user’s world. That mismatch is the “root cause” of the request.

Next, discuss various options to resolve the “root cause”. Usually the best option is not adding a button, but something else that is both technically sound and often far better at fixing the user’s problems. You can’t fault the user—a button was probably the only technical term they knew.*

In the last few years after learning this technique I’ve had these conversations many times. It takes a few minutes, but in the end it saves a ton of time/trouble.

---

Jeff’s Book Recommendations:

Innovation and Entrepreneurship is a great book for those of you considering a startup. Drucker lays out a very logical and useful framework for innovation that is well worth checking your business plan against. It is equally applicable for those in established companies looking to branch into new products.

 

Why Didn’t it Take Off? Pathology of a Floundering Web 2.0 Startup

Tipjoy is a web startup for tipping web authors/personalities funded by Y Combinator. It went live in February to decent press coverage. The concept is simple—if you see something you like tip the author by either clicking on participating author’s link, using the Tipjoy bookmarklet or going to the Tipjoy site and entering the URL.

It’s a good idea and the founders have worked hard to overcome a number of the inherent problems with small money transfers. However, there’s one little problem remaining. It’s not generating revenue.

On the main page of Tipjoy the technically savvy, but perhaps not as financially savvy, authors post their latest statistics:

 $2,519.01 (red arrow) is not a large sum of money. Compound that with the time period indicated by the blue arrow. Elsewhere in the site founders explain that they charge a 3% transaction fee. In other words they pulled in $75.57 over 4 months. Nice. Probably doesn’t even cover hosting fees.

Of course this isn’t the full story. There is likely between a few hundred up to a few thousand dollars sitting in accounts either waiting to be given out as tips or claimed by the tip recipients. With money markets at around 2.5% that may represent another $20 in interest. Thrilling.

It appears the failure to generate revenue has had it’s costs. The founders haven’t blogged for nearly a month—and previous postings are uninspiring to say the least. It seems that around the end of March the founders attention wandered from the site—after less that 2 months live! How many successful businesses ever got it right in that short of time? <Right now imagine a typical rant about generation Y’s failure to follow through>

 OK, now clear those thoughts. Generation bashing is never fair. Let’s look at the site itself.

 First, what’s right.

1. Design: It’s an easy to understand, easy to use site. The color scheme is clear and inviting.

2. Concept: The idea is simple and the implementation is straightforward.

3. Technology: Excellently implemented. The site isn’t foundering through lack of technical expertise.

4. Ease of use: It took about 15 seconds to sign up. Try it.

 So what went wrong wrong? Let’s disassemble it a bit:

Product: In my opinion the product stinks. No, not the idea. The idea is great. Not the implementation. It’s a solid web site. But the product. Let me illustrate. As you may know I live in Tennessee and it gets hot in the summer. A few years ago a deer got hit by a car along the road I drive to work. After a few days of that mid-summer heat that thing could be smelled from nearly a mile away. Some people may take from that experience that deer stink. Well, not all deer. Rotten deer. This product is rotten.

Tipping is a very abstract “product”. “Social well being” is probably as close as it gets. One evening my wife and I dined at our local Olive Garden and by bad luck ended up with a barely competent–if that–waiter. Luckily the lady serving tables near us was very good and bailed him out a couple times. Understandably his tip was very small. But on the way out the door I slipped her a couple bucks. She felt good and I felt good.

Replicating that experience on-line is difficult. Tipjoy is notably lacking in that regard. The main page is made up of a bunch of (dry) statistics. Hello, this isn’t Microsoft Excel! What are they trying to sell—business analytics?? Where’s the sidebar advertising how your Tipjoy data can be added to your Facebook/Myspace site? Where’s the banner that says “Show your girlfriend you really like her latest Facebook post?”. Where’s the “attach a message to the tip” feature? Tipjoy is a social site—it must market itself as a social service. It must integrate into life, or life will continue to pass by outside of it.

Advertising: People have to know about a site in order to use it. Tipjoy did enjoy good initial coverage from TechCrunch and other scattered outlets. However, it lacks long-term support. If I were them I’d contact as many bloggers and Myspacers (if that’s what they’re called—I’m getting too old school for that stuff) to include links on their sites. Tipjoy must become integrated into the social framework.

And one last thing. No credit cards? Hey dudes, it’s 2008, Web 2.0. Instead of “Coming Soon” it should say “transaction charge”. Leave the choice to the consumer.

Lesson: To succeed in Web 2.0 your site can not be an optional layer added to people’s lives. It must be inserted directly into the lives of the consumer. Until Tipjoy finds that recipe it can only founder.

Like this article?  Leave me a tip

---

 Disclaimer: I have no investment in Tipjoy, nor do I have any business relationship with the company. I don’t know the founders personally, but best wishes to them. I have only the greatest respect for anyone who has the guts to start a new company. My analysis may sound harsh, but remember that anyone who gets as far as Tipjoy is clearly a star.

---

Want the same analysis on your web 2.0 business?   See the about page for details