Web2.0 revisited

On June 4th I presented my Web2.0 briefing to 21 participants representing 17 companies at an event hosted by Matrix Resources. Matrix offers briefings to its customers as a complimentary service and from the comments I heard as people were settling in for my talk it seemed to be a much appreciated program.

During the event I captured some informal statistics from the audience on specific Web2.0 usage patterns.

As a percentage of participants how many:

Use Wikipedia?- 100% as reader. 0% as author.

Author a blog? - 0%

Use Digg? - 10%

Have a LinkedIn Account? - 76%

Have a Facebook Account? - 76%

Have used Craigslist? - 76%

Participate in Second Life? - 0%

Use Twitter? - 24%

Use Ajax to develop apps? - 15%

So what does this mean? Like most statistics with small samples... not much. But I like to ask people and see if any trends are appearing that are different then the official surveys.

Also during the briefing we had a lot of discussion about how companies developing web2.0 apps are realizing revenue. The table below is my analysis of some of the more popular companies I mentioned in the talk.

I have added this table to my Web2.0 presentation page 32. In general I found that the strategy for most of these companies is to give the functionality away for free and rapidly grow a large user base. As the application matures and more users are locked in they obtain revenue streams through a combination of advertising and premium services.

Johnny goes to Harvard

Last weekend I attended the Deep Agile 2009 conference at Harvard University. This two day conference was put on by Agile Bazzaar, an ACM Chapter dedicated to the improvement of all things agile. Approximately 90 attendees participated in the conference and I thought that this was a very well run production. Kudos to the Agile Bazzaar volunteers and especially Nancy Van Schooenderwoert who chaired the program. 

The links above give the highlights from the events and I only want to add my own observations:

Jack Ganssle represented the non-agile development community and gave several presentations on his approach to embedded systems development. He favors object oriented development and follows Bertrand Meyer's Design by Contract process.

James Grenning was one of the original signers of the Agile Manefesto  He says he attended that event for the skiing but I suspect he had more involvement... He is a strong advocate of Test Driven Development, Pair Programming, and SCRUM. He showed all these elements to the audience but in some cases they were the regular versions without a significant embedded twist.

Russell Hill is a development manager at Key Technologies. He is an advocate of Test Driven Development for embedded and thoughout his presentations talked about his experiences at Key building a reusable set of boards for the various products Key manufactures. This system includes hard real-time behavior developed for an FPGA connected to a Motorolla micro processor handeling the UI and control logic. He brought a valuable perspective to the conference on what is achievable for embedded development using agile.

Here are my notes from a panel session:

In practice how can a HW based system be delivered incrementaly?

James - I don't do a lot of HW dev BUT "is it working?" is a good test.

Russel - Our HW is based on FPGA and has some flexibility. But boards would be developed incrementaly.

Jack - There is a lot of religion in agile.... HW tends to be late and broken.... and we don't anticipate that for SW

Do you expect to modify an embedded system on a 2-3 week sprint cycle?

James - would like visable progress without neccessarily being deliverable

Russel  - Key Technology can turn around a HW change very rapidly (2 days!)

When an embedded system is used for a consumer product who is the product owner?

Russel -  We have thousands of customers, Marketing dept, Field Serices represents the interests of the customer. Nancy - any problems with that. Russel - Sometimes. Only in last couple years has marketing been strong participant.

James - this is an organizational problem (of getting participation)

How to reconcile "HW requires long lead times" vs "Agile is incremental" ?

Russel - Board was not available for a couple years. SW was written to spec and was able to deliver 2 weeks after HW release.

Jack - Up front commitment to HW features and to the schedule is different for embedded.

James - At the beginning of an agile project one needs a vision of both HW and SW.

How do you handle scheule constraint.

James - in agile nothing is negotiable until it is late.

Russel - when we are late our internal customers now about it real soon. Visibility to decision makers is important.

Jack - This is not unique to agile. Quality, Schedule, Features pick any two. Jack thinks features should be unconstrained while keeping Quality and Schedule fixed.

Any experience including HW engineers in the SCRUM.

Russel - intersted but not active daily 

James - integrate early and often. Some teams use HW engineers as customer. One client in Finland does overnight board turns.

For an embedded system can a product backlog include User Stories that target either HW or SW? If so, what does a HW User Story look like.

Russel - We have not done that.

James - if you try it write a paper.

Jack - I think it would be very difficult.

I am concerned about the lack of upfront design. What if a User Story requires a big change?

Russel - we just experienced this with a project that required a substantial redesign. The requirement was given a year ago on an eight year project.

In classic agile the key to development is decomposition of the epic story into slices. How do you decompose in embedded?

Russel - Frankly we struggle getting our HW engineers to think agile but it is getting better. We had one example where a story to eliminate a spurious image required both sensor, hw platform, and sw.

What role if any does architecture have in agile?

James - we work on it every day. Every time a sprint is completed there is an architecture that supports SW completed to that date.

Russel - Some of our architecture is harder to change. 

Jack - Architecture and Design in embedded world is a lot less maliable. Up front design is very important.

Nancy - Some companies have a culture of detail which is driven by politics.

My question was the one about HW User Stories.... I am still looking for a way to weave the EE participation into a high tempo devlivery using agile approaches. I will take James up on his suggestion to write a paper when I have it all figured out.

mobile check-in

As a road warrior I am always interested in anything that will improve my experience in the airport. I recently saw where Delta Airlines and the TSA have teamed up to trial a paperless boarding pass at the Memphis airport.  The traveller can download an electronic boarding pass that is displayed on the device. The TSA has a 2D bar code scanner that verifies the boarding pass and Delta uses its current gate scanner. So as a time saver, the time at security and at the gate is not reduced, however I save the time in line at a kiosk to pick up a boarding pass. 

Getting the TSA and Delta personnel familiar with the mobile device is a good step to what I hope will be the next big change... Near Field Communication. Instead of using an optical scan the NFC enabled device can be waived over the reader and convey equivalent information as the 2D Bar code. So why is that an improvement? 

1. In an NFC enabled device the eBoarding Pass is kept as encrypted content on a separate chip that is more secure then the device general memory. Hackers can attack a mobile device in several ways and could steal or corrupt the information. The NFC devices resist unauthorized access.

2. NFC will be used primarily for electronic replacement of credit/debit cards. Using the tap and go ISO 14443 based interaction will become second nature to users of the device.

SES becomes eTechSuccess

When I restarted Software Engineering Strategies last year I had planned to incorporate as an LLC at the beginning of 2009. I submitted all my paperwork and then was told by the North Carolina Secretary of State that the word “engineering” is reserved for those companies licensed by the North Carolina Board of Examiners for Engineers and Surveyors. They in turn required the company to have 2/3 ownership by certified professional engineers.  My options were to request a letter of non-objection to using the E word, to become certified and then licensed, or to change the identity of my company. I chose the latter. So what to name my new and improved company?… I had not been 100% satisfied with the SES name because I was doing a lot more then offering strategies on software engineering. So I went back to my web site and read the opening sentence “My passion has been the application of emerging technologies to successfully solve real world business problems.”  The first rename was to call it Emerging Technology Services but while the LLC was not in use in NC the domain names were hard to come by. Finding a good domain name these days is a struggle. So the next variation was Emerging Technology Success because I thought a key experience I had was the successful application of an emerging technology. The statistics I quoted on my website are “Over a period of nine years while I was the practice executive we had approximately 2000 engagements with customers. These could range from small two day workshops up to multi-year development projects. Of these 2000 engagements approximately 100 were considered "Troubled". This meant that the project had slipped and the contract profitability was at risk and/or customer satisfaction was bad. Of these 100 Troubled projects all were eventually resolved. We never had a contract canceled due to our failure to perform. “ So a key idea was taking an inherently risky technology and being able to successfully deliver an application that provided business value. So Emerging Technology Success it was. But the words just did not trip off the tongue and I imagined people trying to type  jbaker@emergingtechnologysuccess.com   so I contracted it to eTechSuccess and it sounds pretty cool. I also added the little wave logo to the business card and website to symbolize waves of technology. It reminded me of the times when I was a young boy on vacation in Florida. We stayed on the Atlantic side and I really liked playing in the surf. But when the surf was high it felt like the waves would keep crashing on me and I would barely recover from one when the next would try to topple me over. Eventually I learned a strategy for coping with the surf just like over many years of working with emerging technologies I have learned how to successfully ride a new wave of technology.

Failure to Launch

When I attended the Cloud Camp last November I had run a session called "Failure to Launch" which was members of the audience talking about their early experiences with Cloud Computing. I was looking for some lessons learned and possibly some unique risk factors associated with Cloud Computing. What I heard was that projects in the cloud are influenced by factors common to most other emerging technology projects. The best example was given by Uri Budnik of RightScale. He had to keep the customer anonymous but did share the following:

Name of Project - Planned Major News Event for major news media 

Project Dates - Project began three weeks before hard news deadline

Technologies used - AWS EC2, RightScale, HAProxy, DNS round robin, Mongrel, My

What happend? - The system was unacceptably slow in early versions and could not be improved. Some of the content would not load. The customer introduced a last minute architectural change the morning of the event that required rollback in order to launch. 

Lessons Learned - Need more through testing.

I heard some similar profiles from other participants about classic software engineering problems...  scope creep, lack of testing, lack of communication with stakeholders, unrealistic schedule expectations.

In the Clouds

Last week I attended the Federal Cloud Camp in Chantilly VA. This event had over 150 people attending. It is an un-conference with people from the audience able to propose a topic for discussion. Over the five hour conference there were 5-6 five minute lightning presentations from the sponsors and then three time slots with four rooms being used = 12 presentations from the participants. Yours truly lead a session on "Failure to Launch - lessons learned from early experiences in Cloud Computing". I will post a seperate blog on that in a few days. In addition to running my session, I attended a session on Hadoop / map reduce and one on applications for the cloud.

I heard some discussion over exactly what Cloud Computing is, comparing and contrasting with SaaS, Utility computing, Grid computing, and Autonomic computing. I believe most agree that Cloud Computing has aspects of all these plus the characteristic of server transparency to the application and user.

The Hadoop session had some users who were experimenting with the technology. For example, one individual from DOD had taken 23 Playstation3 and was running map/reduce between the systems and also on each of the cell co-processors. 

During the Cloud applications session there was a lot of discussion about how to improve applications. One speaker thought having stateless applications improved portability wihile another thought that middleware could manage state transparently to the application.

My general observation is that Cloud Computing is still embryonic with a need for standards developed to allow application transparency accross Clouds provisioned by different vendors.

The Pampered Pooch

Last night I joined a crowd of 18 at the Agile RTP group, which was not a bad turnout considering it was election night. We were there to participate in a "59 Minute SCRUM" facilitated by Bob Galen of RGalen Consulting Group. After a 20 minute levelset on what SCRUM is, we divided into three teams of six and elected a Product Owner and Scrum Master. The goal of the iteration release was to deliver a compelling brouchure of high quality for a Doggy Spa called the Pampered Pooch. We had a existing product backlog of approximately 20 user stories. The timeline of our iteration was as follows:

Iteration Planning - 10 Minutes
Sprint Day 1 - 10 Minutes
Daily SCRUM Meeting - 5 Minutes
Sprint Day 2 - 10 Minutes
Sprint Review - 14 Minutes
Debrief - 10 Minutes

Our team of six members had someone with a laptop and wireless access to the printer where we were meeting. While other teams were hand lettering, cutting, and pasting. We were able to produce a polished look feel. Unfortunately, the mechanics of going from several copies of rough draft to one editor caused us to log jam and not have all the content delivered on time.

So besides the fickle nature of modern technology what lessons did I learn about Agile?
1. Achieving the right tempo of working seperately and then coming together to coordinate is critical. On a real world 2-3 week sprint the daily standup may be the right tempo but I would not preclude adhoc meetings for bringing people together for a focused purpose.
2. Having a flexible Product Owner willing to change direction based on what is being discovered is very nice to have.
3. When the team gels and works well the feeling of accomplishment is terrific and exhausting.

All in all, an enjoyable evening at aRTP.