Innovation, academia VS industry

Last week I was presenting the paper me and my collogues wrote. You can find it here: Enabling Testing, Design and Refactoring Practices in Remote Locations.  The paper was accepted for ICST 2011 conference workshop, RefTest. It is a short paper about problems and some solutions for practice transfer in distributed team.  However this is not what I would like to write about.

The workshops gave me something to think about. The whole conference was targeted at bridging industry and academia together. Unfortunately at the track I attended there was only two papers and presentation from the industry (one was mine).

I was hoping to hear some new innovative ideas that I would be able to take into my everyday work. After a whole day of workshop sessions I was left with no extra ideas. Plenty of smart academic people were presenting research that I found rather useless in everyday life.

I was also little disappointed after the presentations, as none were actually summarizing the research in a way useful for the industry.

I thought of all those blog articles, posts, tutorials, video presentations, etc. from industry people with the ideas and the way of using it. Of all the technical innovations, processes, practices that got discovered in last few years.

Does it mean that academia lost their leading role in software development industry? There is very little in press about new discoveries in the field of software development.

Thoughts?

Greg

 

Evernote as blog software

From Evernote:

Evernote as blog software

I was looking for a good software to use as offline writing tool for my blog. Something in the line of the great Windows Live Writer. Unfortunately some good candidates for Mac were not free.

I’m using Evernote to store notes of different kinds for my ideas and research. Idea just popped into my head that I could use one of the Evernote’s notepads to create blog entries. Each note could be a separate entry.

Evernote has editor that enables me to style it. The only thing that is missing is the “Post to blog button”. WordPress.com gives a possibility to post by email though. I will give it a try now.

If you see this post it means that it was a success 🙂

If by any chance you are a Evernote developer or could influence the features, you might consider my simple idea.

Cheers, Greg

Edited after this line.

As you can see Evernote adds additional header. Pity as it could be such a great way of hacking Evernote and WordPress.com together 🙂

Innovation at Google

Light bulbLast week at CQon London 2011, one of the day’s opening session was Patrick Copeland from Google, talking about the way they innovate. Thoughts that speaker was trying to get across:

  • Idea is only 1% of the successful innovation, 99% is constant repetition of try and fail cycle. Thomas Edison as an example of the cycle that lead to invention of a light bulb.
  • Every idea can be a winner or a loser. Twitter was never suppose to catch up and Windows CE was suppose to be the greatest mobile platform.
  • Surround yourself with innovators, not thinkers. Look for track record of innovation in portfolio/cv.  Innovators beat ideas.
  • Build fast, build the THING, and don’t worry about the RIGHT way of building it. Just get it out. Iterate fast. Dare to fail.
  • Create Pretotypes. Google’s Android application design kit contains a paper clip and a pencil. Draw your idea, application on a piece of paper. Put it into pocket and try to use it like a real thing.
  • More time you spend on the idea without releasing it, the more in love you’ll be with it. Therefore less likely to dump it.
  • Data is apolitical and factual. Use data not opinion to decide upon idea, if it’s worth doing, if the prototype/prototype/beta is getting more popular, etc.

Are you feeling like innovating something now? Go and do it 🙂

Scalable Lean and Agile, QCon London 2011

qcon-londonToday was the first day of QCon 2011 in London that I attended. I thought about sharing what I remembered while it is still fresh in my head (and the head is buzzing with ideas).

Craig Larman spoke at opening note and at one of the sessions. Embarrassing that it is, I never heard about Craig before, neither I read any of his books. I did enjoyed the way he presented his material.

Craig was talking about scalable, distributed agile teams. Apparently he has a lot of experience working in this kind of environment, gathered throughout many years of his professional career.

Craig described a typical situation where delivery teams are physically located in different countries, working on the same project. In his presentation he provided practical tips for dealing with issues that rise in distributed environment.

The most important points that Craig delivered in his presentations are:

  • No disperse team – all the teams are sharing same goal and work as equal partners. There should be no hierarchy in teams.
  • Practices should be shared and guarded by Committees of Practice. Committee should have a leader that gets slack time to overlook the Practice and organize teams appropriately.
  • Software design should emerge as a collaborative work during workshops. Embrace open space in the office and lots of white boards.
  • Diverge and merge – teams should come out with design on their own sites, then they should hold Video, show and tell session with all the other sites.
  • When teams come with design on a specific part of the system, team leaders should work across all teams to have a common design for the whole system.
  • A documentation workshop after iterations embraces knowledge sharing and collective code ownership.
  • Avoid PowerPoint architects. Architects that are so far away from the code that they became architecture astronauts.
  • Component guardians are team members who look after code across all the teams, making sure that high quality is kept. If only one team takes care for only one component, the crap code is going to be maintained and accepted within. Teams needs to be cross component and cross-functional.
  • When components involve public interfaces, start with weakly typed, for example do ( aMap ). Once you know more and more code is stabilized you can make those more formal and strongly typed.
  • Continues integration is a must have.
  • There is a need to see the people across all teams. It builds trust and respect. Try to use cheap technology like Skype and web cams.
  • Team members should meet, rotate and travel to other sites.
  • Keep on thinking and adapting your methodologies and processes. Never retire.

Above points are mainly from the keynote Craig was giving. The second session was more about contracts and collaboration on “offshore” delivery model.

Some more interesting points:

  • Outsourcing development you will have to deal with culture, language, knowledge, domain, skills difference issues.
  • Address skills difference via internal education. Brown bag sessions or workshops made by more experienced team members.
  • Avoid single point of contact with the team. Visit teams before project kick-off. Physical contact is very important to create relationship.
  • Ask and rephrase questions in different way (or from different viewpoint) to test the answers.
  • Encourage team members to say no when needed, remove fear.
  • Don’t patronize teams capabilities by giving simple, disconnected tasks. This will reduce morale and make people leave, as they would think their job sucks.
  • Before project kick-off organize Domain Workshop (so the team can understand the domain) and Vision Workshop (so they can understand what to deliver).
  • Specification by example.
  • Make sure team is stable as much as possible (no leavers and joiners).
  • Make it clear that at the end of every sprint you are expecting a shippable product with the number of functionality developed.

Many of the things that Craig was talking about can be found in his book “Scaling Lean and Agile development”.

Many more info and a good introduction to Lean Software Development can be found at Crag’s web site. You can also enjoy a video of him telling a bad joke 🙂

Cheers, Greg