Jason Grigsby on the Mobile Web: Where are we Going?

Tonight at the Portland Web Innovators group Jason Grigsby gave a presentation and led a discussion about the mobile web. He’s very passionate about mobile and presented some interesting statistics about mobile device usage and adoption rates (the U.S. lags far behind the rest of the industrialized world).

One of his major points was that the mobile web space is currently in a situation similar to that of the general web in the mid 90’s. Standards are absent. Most people aren’t yet on the platform, but it’s quickly growing. There are many browsers. Each browser renders content differently. Nobody is sure who will “win” the browser wars. Nobody knows the direction the mobile web will take.

It’s an exciting time for those who want to jump into mobile. Porting existing web applications to the mobile space is one aspect to the situation, but the real innovation in the mobile web will be with applications that haven’t yet been invented. Who would have thought a few years ago that one of the biggest mobile apps would be a hybrid web/SMS system where folks can send 140-character responses to the question “What are you doing right now?”. As mobile device adoption rates grow, new b2b and consumer applications will rise.

There was a brief discussion about tools; right now all of the major phone manufacturers (except for Apple) offer developer tools such as emulators to help with development efforts. Jason mentioned at least one vendor that is offering commercial tools that help translate code between devices. The commercial tool wasn’t cheap, which brought up another key point: at this point in the mobile web game, tools can be expensive because they’re rare. That stinks as a consumer, but is a great opportunity for someone who wants to work in the dev space.

As someone who started working in the web space in 1995, the next few years could be very interesting if things parallel the development of the web.

Keep an eye on the CloudFour blog, where I’m expecting Jason will post some followup information/links from his presentation.

[tags]mobile, mobileweb, pdxwi, jasongrigsby, grigs, cloudfour[/tags]

Creative Design and Clear Specs

For Christmas I received the book Dreaming in Code by Scott Rosenberg. I’m about halfway through, and Rosenberg interesting point about specifications. They are, by definition, specific (or at least they should be). Developers will write to the spec. Whether the spec solves the business need is a separate issue, but when it comes to software construction (like any type of construction), given a well-written specification the developers should be following the specification to the letter.

However, developers also need to get creative when participating earlier in the process, during design. At many shops (every shop I’ve ever worked at), developers will play both roles, participating in design and then later in construction. This dual role of creative thinker and rigid document-follower is an interesting paradox, a situation where in performing the duties of ones job, the mind needs to be creative and come up with new ideas, then reach a stage where new ideas are inherently bad and potentially project-damaging.

Perhaps the ideal programmer would have some sort of controllable multiple personality situation…

[tags]softwaredevelopment, software, developers, dreamingincode, scottrosenberg[/tags]

Hanselman and Bradbury: Tech vs. Life

I read blogs by a number of software developers, and two of the ones I respect most are Scott Hanselman and Nick Bradbury.  As I was catching up on some reading I noticed that in the last week, both of them addressed the topic of work vs. non-work balance, including the issue of leaving tech life “on the job” or whether ones technical mind should continue to work after hours.

Scott’s post talked about how he dislikes working with “5:01 Developers” — those who mentally check out at 5:01 and drop their working/technology thoughts as they transition to home life.

Nick advised folks not to trade their lives for tech, getting out and enjoying a social life and afterhours culture that doesn’t revolve around coding, development, or technology at all.

Two bright guys making two statements that seem to contradict each other a bit.  Who is right?  Which is a better developer?  Someone who lives, breathes, thinks, and writes technical code 24×7, or someone who clocks in, does a good job working for a “normal” workday, then leaves his technical job behind as he moves on to have a non-technical social life in the evenings?

Honestly, I think there can be advantages to either lifestyle.  Someone who works on technical activities all the time might have a technical advantage, but that advantage might come at the expense of social activities.

Where do I fall?  I’d like to think I’m somewhere between the extremes.  As a software developer, I spend 8 hours a day writing code or participating in other development activities.  After hours, I blog, read technical articles, and have been known to be seen at a user group or forum.  On the other hand, I write very little code after work.  I enjoy time with my family (which grew by one member last week) and enjoying photography and other hobbies.

[tags]scotthanselman, nickbradbury, developers, softwareengineering, technology, work, family[/tags]

Things I Learned About Software – In and Out of College

Here’s my few thoughts on the “Three Things I Learned About Software” meme that’s going around. As prerequisites, read Dare and Scott who seem to have started this all.

Three Things I Learned About Software in College:

  1. It all boils down to the same old data types.
  2. Business problems are not solved by programming languages.
  3. Occasionally the code you pull out of your ass at 2AM will be just the thing you need to finish a project. Occasionally it won’t.

Three Things I Learned About Software WHILE NOT in College:

  1. Just because someone says they have business knowledge and their title is Business Analyst, they may or may not have any knowledge of the business problem the software is attempting to solve.
  2. That code you write as a quick/dirty interim solution will always be in use for a longer period of time than intended.
  3. Everyone thinks their code or situation is new, unique, different, and doesn’t need to follow established patterns and practices. In reality, it probably isn’t special at all.

[tags]software, development, softwareengineering, college, dareobasanjo, scotthanselman[/tags]