Hi tech slavery revisited

I have a friend who was a senior employee in a couple of start up companies. One even yields him a nice capital following its purchase by a USA company. For some reason, however – he decide to start his own start up company. Something to do with bio medical devices (he meet a doctor who thought about the idea that the device is based upon). The company was started with a small capital in a VC green house. My friend is CEO and the inventor and initial investors form the board.
Work, work, work
Not lately, he was able to secure a 2nd investment round (a million dollars, give or take) and the board got some new faces to represent the new investors.
My friend is now busy all day (and night) in tours around the world (when they needed the money and looked for investors), preparing the board meeting, going into medical shows, etc.
He hardly sees his kids and family (which lead to a family crisis IMHO), hardly has fun and work himself to death. He claims he enjoys it compared to his past payroll employee (however high ranked).
I think he enslaved himself to the hi tech beast.

The future of Windows Mobile

It is no secret that I work in one of the most experienced Windows Mobile development ISV company. Lately we were wondering about the future of Windows Mobile. Traditionally, we developed Windows Mobile applications in C++ (for the Pocket PC platform). We used MFC throughout Windows Mobile 2000, 2002, 2003, 5.0. For the Smartphone platform we plunged right into .Net Compact Framework.
While working on our latest Windows Mobile 5.0 products, we suddenly encountered some MFC changes that broke backward compatibility. We also seen the effort put in by Microsoft to promote .Net in general and for mobile development in particular.
Fears begun creeping in: will MFC future is doomed? Will we still have Win32 API’s in future Windows Mobile releases? What will the Pocket PC and Smartphone unification bring for developers?
We are now faced with decisions regarding our future Windows Mobile development technology. Basically we can:

  1. Stay with MFC and face its fate bravely.
  2. Move to Win32 APIs (or create our wrappers around it).
  3. Switch to .Net CF (and suffer the performance penalty and the hardships of doing non standard “things” with it).

What do you think?

What should be our future Windows Mobile development technology?

View Results

Loading ... Loading ...