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

Innovation at Google

Light bulb Last 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-london Today 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

QCon summary (my presence on Thursday)

I got the opportunity to attend some of the sessions on Thursday QCon London 2010 conference.

Quite a large number of interesting tracks. It was really hard to choose which one to go to. I decide to throw in a mix of everything.

Kicked of with Christopher Reed, a colleague of mine, and his talk on different Cloud solutions out there, and also what are they good for. Chris was emphasizing the trend in the industry. A lot of companies deciding to go into cloud as if could could be a solution to all their IT problems. Chris was pointing out that it is important to make a proper decision what solution to go with as they are solving different problems and require different treat and behavior from the organization. It is impossible to get the most of the cloud and actually not get into more trouble if you don’t accommodate the fact that you are in different environment now. I liked how Chris was dividing cloud solutions into areas based on Processing Speed needed and Data Sensitivity where Processing Speed means how fast you wont your computation to be done and how complex they. Data Sensitivity meant the amount and data importance, for example crucial amount of financial transactions versus widely available weather information served by a web site.

Second talk I was at was from another colleague of mine that actually I never had the opportunity to hear speaking live, Rebecca Parson. Rebecca was talking about the ways that people not skilled in the domain can come out with some really great solutions. She encouraged diversity and cooperation in a teams that could lead to better solutions to any kind of problems.

After Rebecca’s session and a lunch break I went into a presentation by my former colleague, Dan North. I find Dan one of the best entertaining technical speakers there. His fascination about the ways the human brain learns makes his talks always very informative and fun.

Dan was talking about the way human brain tends to see patterns, generalize and then complexify solution as a result. Very often there is no common functionality and there is no emerging patter.
I liked one of the quotes he used in his presentation:

Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems.”
–Jamie Zawinski, 1997

Fishbowl discussion was last session. The topic was about the Future of Software development. It appears that there is emerging trend in the industry to follow the simplicity and go back to a roots of software development. Simple design and good algorithms over frameworks and bloated architecture. This trend appears to follow hardware development and new presence of mobile devices on a market.

Overall very interesting day. Pity I couldn’t make to all the sessions as they were all interesting 🙂 Hope my colleagues who were at different presentations could share their views and notes if possible.

Greg