iPhone - Product of the Decade

So yeah, I guess this might be another iphone fanboy post..but I thought I'd focus on an area which is of special significance to me, and one which also hasn't gotten a lot of attention...the soft keyboard.

In most of the original efforts to launch highly portable devices or tablet computing, most takes on a new model included a stylus and some form of handwriting recognition, the assumption being that the model for an ultraportable computing device had to be a pen and notebook.

It was the MODEL for tablet and smartphone/pdas which was wrong...and mostly because no implementation could be made seamless and elegant enough to come close to rapid, easy handwriting recognition..and the interfaces for stylus with handwriting recognition were all (possible exception Palm) horrible and clunky.

What Apple has really accomplished with the iphone is to create a new model for interacting with a computing device. The risk they took was whether the soft keyboard would be accepted. At the launch of the iphone, the most successful mobile device/smartphone was the blackberry, and blackberry had "proven" that a smartphone HAD to have a keyboard, and some would say that that keyboard had to be physical.

By executing so well on a gesture based interface model including a soft keyboard, Apple was able to create a clean, simple, and highly compressible UI that was a perfect model for smartphones, and will very likely prove to be a perfect model for tablet computing as well.

As imitation is the sincerest form of flattery (and of proof that a new model vs simply a new product is on the move) Google is playing Microsoft and copying the Apple model with Android. It remains to be seen which companies products will dominate the tablet and smartphone markets, but wc can be certain that the model has changed, and we are once again on the verge of a sea change in computing.

This coming decade will be defined by computing and data mobility, inextricably linked with social networking and geographically aware applications. Its going to be interesting looking back in 2020.

Happy New Year!

Geek days of Xmas

Okay, so before you comment, yes, I am aware that this song would be more efficient if implemented as an array of 12 verses with a couple for next to iterate..

Also, I know some will be horrified by my use of goto, but I never claimed to be a very good coder in the first place. As I'm often fond of saying, those who can't code, manage.

The Twelve Geek Days of Christmas

On the first day of Christmas my true love gave to me, a method to read a pear tree.

On the second day of Christmas my true love gave to me, two semaphores and a method to read a pear tree.

On the third day of Christmas my true love gave to me, three for nexts, two semaphores and a method to read a pear tree.

On the fourth day of Christmas my true love gave to me,four pound defines, three for nexts, two semaphores and a method to read a pear tree.

On the fifth day of Christmas my true love gave to me, five buffer rings .. four pound defines, three for nexts, two semaphores and a method to read a pear tree.

On the sixth day of Christmas my true love gave to me, six sleeps delaying, five buffer rings .. four pound defines, three for nexts, two semaphores and a method to read a pear tree.

On the seventh day of Christmas my true love gave to me, seven whiles a looping, six sleeps delaying, five buffer rings .. four pound defines, three for nexts, two semaphores and a method to read a pear tree.

On the eighth day of Christmas my true love gave to me, eight threads a racing, seven whiles a looping, six sleeps delaying, five buffer rings .. four pound defines, three for nexts, two semaphores and a method to read a pear tree.

On the ninth day of Christmas my true love gave to me, nine gotos going, eight threads a racing, seven whiles a looping, six sleeps delaying, five buffer rings .. four pound defines, three for nexts, two semaphores and a method to read a pear tree.

On the tenth day of Christmas my true love gave to me, ten files compiling, nine gotos going, eight threads a racing, seven whiles a looping, six sleeps delaying, five buffer rings .. four pound defines, three for nexts, two semaphores and a method to read a pear tree.

On the eleventh day of Christmas my true love gave to me,eleven pipes a piping, ten files compiling, nine gotos going, eight threads a racing, seven whiles a looping, six sleeps delaying, five buffer rings .. four pound defines, three for nexts, two semaphores and a method to read a pear tree.

On the twelth day of Christmas my true love gave to me, twelve twelve objects running, eleven pipes a piping, ten files compiling, nine gotos going, eight threads a racing, seven whiles a looping, six sleeps delaying, five buffer rings .. four pound defines, three for nexts, two semaphores and a method to read a pear tree.






-- Post From My iPhone, typos included

Location:Lorraine Ave,Montclair,United States

FOX News, and why we should be boycotting it.

There are speakers who inspire, challenge, uplift, or educate, and their audiences are perhaps inspired to continue thinking about an idea, or to consider action. Good examples include our President, Martin Luther King, JFK, FDR, Lincoln, Edward Murrow, and many, many other inspiring and notable politicians, journalists, authors and religious leaders. These are people who change the world by giving life to a dream or an idea of what might be. They invite people to think.

And then there are speakers who incite and deliberately evoke hatred or play on base human fears. These speakers deliberately create a mob. A mob does not think. It is directed in its anger and frenzy at a target and then unleashed. An audience has its mind engaged. A mob has given in to base emotions, devoid of any complex thought.

In 1984, George Orwell paints a picture of a totalitarian state so extreme, it can be said to far outstrip the reality of any state in existence today. The novel resonates with the reader because like any nightmare the root of its horror lies in our own souls and the glimmer of possibility contained therein. It presents a caricature, but like all caricatures, one can discern the underlying features which exist in reality.

In one scene in the novel, an institutionalized "3 minutes hate" is mandatory viewing for all the good citizens. Its cynical purpose is to reduce the watchers to a howling mob, giving them unity in their hatred and fear in a completely unfocused, irrational state of mind.

When you examine FOX from this perspective, it's easy to draw parallels from the caricature... FOX chooses issues which can be easily distilled to a shouting match. It decides which side will play best to the audience which it is attempting to incite and then it provides a solid 30 minutes outrage and anger to that audience.

FOX is playing on white americas fear of change. Fear of change to a multicultural america. Fear of other customs and languages. Fear of a globalized economy where jobs move. Fear of other religions, of educated people, of change. At its simplest, fear of THEM. FOX plays on these fears with imagery, symbolism, and rhetoric, but FOX doesn't ever discuss whether or not there's really a rational basis for any fear.

The emotional qualities FOX elicits in its coverage unify its audience. This unity isn't based on any reasoned discourse..a parody of discussion reduces any issue to a binary question, with a right side, and a side reserved for scorn and hatred. The part of Emmanuel Goldstein was well filled formerly by the bespectacled Colmes.

Outrage generation is the business of FOX.

The result is a constituency that can be incited to act. In the case of 9/12, that action was prompted and supported by FOX Rodeo Clown in residence, Glen Beck. FOX will then cover the acting out and decide what the crowd is really angry about.

And so we have a 9/12 gathering where a mob has gathered, to protest everything from healthcare to the appointment of Czars, with a certainty that we are moving as a nation towards some type of socialist, communist or fascist government. The crowd is pro Joe Wilson and Sarah Palin and is against anyone who might be Hitler.

The scariest carry signs with not so subtle threats of violence and talk of revolution. Confederate flags and gun rights advocates are sharing a tent, and pictures of Obama in whiteface mix with Kenyan birth certificate fictions..but this is not to be construed as racist.

The FOX lead is that this mob has shown up as a reaction to healthcare reform.

THe irony is that the constituency that has lost the most in eight years of Bush and stands the most to gain from a progressive administration, is used and manipulated so cynically.

So we should be boycotting FOX. It's not entertainment. It's propaganda of the worst kind, designed to eliminate discussion, distort or ignore facts and replace them with anger, fear, and division..and we need less of this, not more.

FOX divides america, which is of interest to its corporate sponsors and owners. A divided america can't reform healthcare, or regulate its financial industry, or change the tax structure to something which might be called fair or reasonable. A divided america keeps the gravy train going for it's corporate masters. A divided America, in short serves the interests of the wealthy and corporations. FOX serves this minority, and uses the very people who are exploited by it as it's pawns and cannon fodder.

FOX divides America. Please stop watching.

#wewanthealthcarereform

In all the healthcare hubbub...

With all the screaming and yelling go on at these town halls, and the fantastically heavy coverage given these "real american" "protectors of the republic", its amazing how much non discussion of healthcare is happening...at the town halls, on the news..even the debate on the net is now centered on the "outrage" and increasingly on the violent behavior and sentiments expressed by the protesters...

...and it seems to me that this discussion is being hijacked by those who have the least to gain and the most to lose, and they are using those who have the MOST to gain and the LEAST to lose to make their point.

It seems pretty evident that the health insurance industry doesn't like ANY discussion of a public option. Even having a conversation about it is a bad idea, because once you have even an inefficiently run not for profit health insurance option, it will in almost have to provide better service for its participants...why?

Because health insurance is a business where capitalism and the free market work AGAINST the consumer. By its very nature, a for profit health insurance company manages the company for the benefit of its shareholders, which means it is always looking to:

Grow revenues (increase the gross number of policies, look for investment opportunities for its cash, etc, etc)

Reduce costs : Manage its business efficiently..and...pay out only what it MUST in benefits.

By doing these two things well, profits increase..and profits go to...shareholders.

In short, a health insurance company, like any insurance company, makes more money by not paying.

The moment you have a not for profit insurance company all that margin that was being used to provide value to shareholders becomes available to the health consumer. There is no longer any incentive to make it difficult to file a claim, because not paying claims no longer makes sense....

but I'm not setting out today to argue my opinion on what we should do about healthcare.

I'm simply saying that there should be a real discussion about it..and that if we all had a real conversation about it, my bet would be that most of us would prefer a system that covered all of us, and that cost less, while still doing a great job taking care of our health as a country and a society.

I'm also pretty sure that system wouldn't be the one we have today.

So as you watch the tea bagger/birther crowd..who are helped to organize by special interest funded groups...(I wonder which ones?)....

get disproportionate (and sympathetic) coverage on certain news outlets (FOX)....just remember what we're NOT discussing...and then go tweet: #WeWantHealthCareReform

Oh, and if you don't buy my statements on how health insurance companies with a profit motive behave, give this a read: Ira Glass on "pre existing conditions"

High Frequency Trading....

Okay, so I've been reading both sides of this debate..and I have to say..what is really new here?

Having watched a few technology transitions in financial services over the last 15 years or so, and I have to say this feels a lot like others, with one big exception.....we really are reaching the point of diminishing returns here.

When we're done giving NYSE and other proximity hosters coin for shaving milli's off a transaction...and transitioning away from the TCP stack for distributed computing to 10G ethernet and RDMA..and all of our cacheing and reliability mechanisms are optimized for sub millisecond trade executions..and all the CPU's are Nehalem....

And service providers provide a level playing field execution capability to those without the wherewithal to build these systems....

Then what? Do we start looking for sub microsecond trading?

This trend certainly keeps alot of technologists on wall street and at tech companies gainfully employed, so don't get me wrong, an arms race can create some nice side effects..but you really have to stop and wonder whether this is creating a better market.

When the purpose of executing faster is to execute smarter, by taking advantage of fleeting price disparities, I think thats a good thing...but when its done to take advantage of fee structures, for example..I'm not so sure.

I think what I would like to see is more reasoned dialogue about where this is going, apart from simply taking advantage of the current market environment to make a short term killing.

What happens when everyone can trade at high frequency latencies?

Once off development and other business myths

The view of development of software is often similar to the creation story. G-d, as the developer, sets a project schedule (seven days) which is of course padded by about 15%. He completes the project on time, which I attribute to the lack of QA (disease, war, hate, bacon being unhealthy as notable defects). Like all good developers, he goofs off on the last day of the project. And then he's done, and it was good.

Many business managers I have worked with view software like this. Why do I need the development team if the project is over?

Now I'm not arguing against retuning the size of teams against workload.. I'm arguing against the extent to which the business believes cuts can and should be made, which stems from a fundamental difference in perspectives.

See, I view software as a living breathing organism operating in the environment of its users and its problem domain. The developers and technical people who operate,enhance, optimize and extend the software are like the internal organs of the organism..they keep the software alive.

The moment the last developer who knows the code leaves, the code is dead. The time it will take to revive it increases the longer this state of affairs continues.

If you reduce the size of a development team, the ability of the software to react to users, its operating environment, and its problem domain decreases; it will have a harder time evolving and adapting. This relationship between the people who create and maintain it and its ability to change is fairly straightforward..however in today's environment where software is increasingly a service, it becomes ever more relevant.

I think most non technical people view software as an inanimate object or tool that solves a problem..so once it's built and is a part of their world, in their mind it's done...and why would you need a bunch of people to keep working on it?

Now I know most non technical people understand the differences when they take the time to think about it. What I'm getting at is that the intuitive understanding of what code is differs significantly, and that can lead to wide disparity when it comes to making business decisions.

Which brings me to my last point...the value of the original team members. As I've said before, developers aren't fungible. The original team is very valuable....they understand the problem domain, the design decisions and their rationale as well as the code itself. The understanding of the problem and the design is of at least equivalent value to an understanding the code.

The short story is..the more the software needs to adapt, the more critical that the original project team (or a higher percentage thereof) remain intact.

When you can say that the problem domain has settled down, the users have no real demands and the business environment for the software as a service is no longer changing at high speed, well at that point you probably need an absolute minimum... but evaluate the environment for your software and the services it provides before coming to any resource planning conclusions.

Ping me back with your thoughts at twitter/schiff.

Thoughts on the business/technology divide

As the software development manager and chief architect for a mid size financial firm, a regular part of what I do is translation between business and technology management.

Despite the fact that more and more is possible, and engineering staff are increasingly productive, the gulf between business and technical management remains one of the most difficult gaps to bridge.

This gulf in understanding is destructive. Business management often views technology projects as opaque and unmanageable ( high risk) Couple that with the expense and it should be no surprise that managers often prefer outsourcing of software projects for cost reasons as well as risk management- an outsourced development which goes awry is a problem for legal..an insourced project is a managers direct responsibility.

The reality, of course is that actually delivering and building software is a complex and difficult game. Doing it across continents, timezones and language/culture barriers doesn't make it easier. If we add in the element of magical or unrealistic thinking coupled with a general ignorance of how building software works...well it starts to be clear why so many software projects fail. In this post, I'd like to touch on my favorite management fallacies. These are in no particular order however they are all favorites of mine.

1) Technical people are fungible
Huge mistake. Most projects are built by 1-5 people, and the best results are generally achieved by several areas of expertise working together. The right team skillset mix makes or breaks a project. Very often, the wrong skill on a task can bring a whole project down.

Projects should be self contained, and if possible all the skillsets required should be present on the team, or assigned for the duration of the project.

2)The project can be completely defined up front
This might be true given enough time and money, however in most cases software evolves over time. The understanding of a business problem at the beginning of a project is often changed by the time the solution appears. This is true of almost any invention - look at bicycles, for example..but in software it happens over the course of its development.

Iteration, and continuous refinement will happen, and should be supported by the management model for projects.

3)Technical people are fundamentally lazy
I sometimes believe that nontechnical managers really believe this, based on the way that project schedules are negotiated. There is never a willingness to consider that maybe the people who have the most direct involvement in writing and testing code are the people in the best position to understand what a given project takes. The fact that a non or semi technical manager has an understanding of the design and implementation does not immediately translate into a true ability to assess the overall difficulty. I have never been in a project schedule review meeting where a non technical manager accepted my schedule. Thus, by long indoctrination, I always pad my schedule.

If anything, in my experience what actually happens is that projects which developers find interesting or believe will be used are underestimated..projects which the reverse are overestimated. Heaven help you if you are a lead and have a boring but mission critical project to get done.

The most important thing you can do to get high performance is to identify work which is truly meaningful to the business and the users it serves, and to keep developers engaged on it in areas that they are good at and if possible mostly interested in.

4) Having QA as part of a development team is letting the fox watch the chickens.

This is one of my favorites, because the underlying assumption is that developers like to ship crappy code. Good developers HATE defects. I have rarely met a developer who, through laziness or a general lack of interest was content to consistently ship defective code. I don't believe developers who operate this way last very long, anywhere. In my experience, most developers are very concerned about testing, and have a deep desire to ship solid code that works and is easy to operate. What they need is help in getting there.

An external QA organization isn't that help..organizationally, its a setup for non stop conflict. Metrics get developed which are used against development and an excuse culture sets in. QA cannot be efficient unless it is staffed by at lease junior caliber developers who can effectively automate tests. Effective automation starts at unit testing and code coverage, so in essence QA starts in development and grows outward as components are integrated. In short, the fox and the chickens are on the same team and likely have very similar technical skillsets in an effectively managed development organization.

Build a product team around developers and testers working together, consistently, around the same code base over time.


5) Putting high pressure on target dates and development managers is what makes projects ship

Or "the beatings will continue".....this is perhaps the worst assumption. You can rarely get good quality work output during the bataan death march.

A business manager can ALWAYS get project schedule concessions through the whole first half of a project from a development manager - through a variety of bullying techniques including -

"If thats the date the project will be cancelled" - it never is...

"Your job is on the line for delivery" - it always is...

"If you can't do this, I'll find someone who can" - possibly, but you'll treat him or her the same way, and nobody is superman

Or my favorite - You gave me an answer i don't like, so I will poll your whole team looking for someone willing to undercut you.

Or last, thats the date, and we'll work the team continuously including weekends to hit it. - never really works.

This approach trains development managers in a technique I refer to as "incremental dissapointment". At the start of planning, a development manager is asked to assess the timeframe for a project. If hes dumb enough to just provide one which is realistic, the bullying will commence.

If hes really dumb, or just starting out in his or her career, he'll hold firm.....in which case he has created an opportunity for a third party consulting firm to quote a better date, or for someone else to lead the project. The smart move is to compromise on a date which the business manager will accept, with conditions that the business owns and will completely undersize (requirements/design review) in terms of time.

This all sounds horribly cynical, but it is a survival model for dealing with dysfunctional business management..remember, the starting assumption coming in is that you and your team are lazy, so you have to be "motivated" properly.

SO my advice to non technical leadership. Trust your technical leadership as a partner..if you don't, find a new partner.



These are just a few of my favorites..next post, I'll be focusing a whole entry on "why do we need developers once the code is written?"







-- Post From My iPhone, typos included

Transactional Web Apps vs Transactional Financial Apps

Some recent articles comparing transactional apps in the financial services marketplace to ecommerce applications are both misguided, and to my mind critically annoying to those of us who have to deal with business people who read them.

Misguided myth: Amazon does more transactions per day then the entire financial services marketplace, so why is this so hard in financial services?

Depends on how you measure it, but assuming its true, does the latency per transaction matter? If amazon drops your bid, does it matter? You just hit "bid" again...is it okay for Amazon to miss a message? What if they tell you you were successful late?...basically...guaranteed receipt of messages at very high volumes in near real time, with absolute limits on latency aren't easy requirements.

eCommerce applications on the web are not held to the same metrics, nor are their transactions subjected to the scrutiny that a typical financial services application is held to.

You think this would be obvious..but you'd be amazed how many people (including people in the industry) actually buy into doing this comparison and then pontificate on how developers doing work in the web ecommerce space must somehow have more on the ball. Maybe its because they write in (fill in the blank scripting language) instead of C++...

Or maybe its because the software industry pundit circuit lacks for good material.

Articles like this do nothing but create misery for engineers who have to deal with business managers who read them.