October 12, 2010 

Minority Report interface is reality

Remember the data interface from Minority Report? Well, it’s real, John Underkoffler invented it and will change the way we interact with data.
Minority Report science adviser and inventor John Underkoffler demos g-speak — the real-life version of the film’s eye-popping, tai chi-meets-cyberspace computer interface. Is this how tomorrow’s computers will be controlled?

“We’re not finished until all the computers in the world work like this.”
John Underkoffler

See original | Download high-res

John Underkoffler led the team that came up with this interface, called the g-speak Spatial Operating Environment. His company, Oblong Industries, was founded to move g-speak into the real world. Oblong is building apps for aerospace, bioinformatics, video editing and more. But the big vision is ubiquity: g-speak on every laptop, every desktop, every microwave oven, TV, dashboard. “It has to be like this,” he says. “We all of us every day feel that. We build starting there. We want to change it all.”

Before founding Oblong, Underkoffler spent 15 years at MIT’s Media Laboratory, working in holography, animation and visualization techniques, and building the I/O Bulb and Luminous Room Systems.

October 10, 2010 

Growing plants in your desk: urban agriculture

GrowingCities is a research and design think-tank focused on exposing the potential in urban agriculture. They believe that the growing movement of local food production has the power to vastly benefit our cities – socially, environmentally, and bodily.

Saranga Nakhooda and Devin Lafo founded growingCities in 2010 upon graduating from the Master of Architecture program at Columbia University GSAPP.

The world’s population is becoming increasingly urban. Understanding, evaluating
and re-envisioning the systems by which cities operate are crucial steps towards creating
a sustainable future, and to affecting positive change through architecture and design.
As city life becomes progressively dominant, we become increasingly distant from our
food sources – a trend that has profound implications in terms of both food security
and environmental impact. On average, major cities import 6,000 tons of food each day,
with an average distance of 1,700 miles between grower and consumer.

These design proposals imagine an alternate possibility, one in which urban dwellers can
grow their own food – expanding the economic base of the city, connecting people to a
natural food cycle, and reducing food cost while increasing food quality.

Some of their urban agriculture proposals are really innovative. Green desks, lamp posts and growing food in empty apartments sound like the way of the future!

June 22, 2010 

3 risks with Agile decision making

Agile teams are generally cohesive and are empowered and expected to make day-to-day decisions. A large part of empowerment in Agile methods is that the team makes the decisions, not the project manager. However, there are some risks involved with this type of decision making. In this article I describe some possible risks.

Group think

The first risk in decision making is group think.

Group think has the following symptoms:

  • Little or no consideration of alternate plans
  • Risk is not assessed
  • No review is taken of rejected plans
  • Advice from outsiders is not sought
  • Facts that support the plan are acknowledged, facts that do not support the plan are ignored
  • Contingency plans are not created

Surprisingly, synergy and loyalty to each other and to the team leader are a team’s greatest qualities, however, they are the same factors that lead to group think.

Abilene Paradox symptom

The second risk in decision making is the Abilene Paradox symptom.

The Abilene Paradox symptom has the following symptoms:

  • Members, as individuals, privately agree on the correct decision to make. This is not shared with the group.
  • Members, as individuals, privately agree on how the problem or situation being addressed can be resolved. This is not shared with the group.
  • Instead of communicating their views, members keep their views and reservations to themselves, agreeing with views they are opposed to. As the individuals have not presented their views and reservations, a collective decision is made that is actually contrary to the views of all members.
  • Members feel frustration, even anger, at this and find someone, or some people, to blame.

The Abilene Paradox is real. How often have you agreed to a suboptimal solution? What if every other team member felt the same way about this solution?

Decision hijacking

The third risk in decision making is decision hijacking. This happens when for example a developer implements features that are not needed right now. The developer hijacks the decision to implement these features.

Example during daily stand-up:
Developer: The customer databases will be used by several applications, so I have implemented support for dealing with various technologies, including Oracle. It took a lot of time. Scrum master: Did we not agree on postponing this? Developer: We need this later and now it is done.”

Decision hijacking is a big problem because the decision making itself is removed from the team as a whole. This behavior has a big impact on trust within the team.

Solutions

Conflict in Agile software development projects can be beneficial to both process and product.

The literature proposes some solutions to the problems with decision making described above. These solutions are based on the existence or stimulation of intra-group conflict:

  • Separate groups should be formed, under different leaders, to propose solutions to the same problem (groupthink)
  • A devil’s advocate should be appointed (groupthink, Abilene paradox)

For the decision hijacking risk, make sure that developers are on the same page. Working together as a team means taking decisions together.

Sources:

  1. McAvoy, John, en Tom Butler. “The role of project management in ineffective decision making within Agile software development projects.” European Journal of Information Systems 18.4 (2009): 372-383. Web.
  2. Moe, Nils Brede, Torgeir Dingsøyr, en Tore Dybå. “A teamwork model for understanding an agile team: A case study of a Scrum project.” Information and Software Technology 52.5 (2010): 480-491. Web.
June 1, 2010 

It’s not about the features!

I believe that any software developing company that wants to have a competitive advantage needs to stop focusing on just building features, but instead focus on the users.

Many companies seem to focus on the checklist of features that are dreamed up by marketing. Most of these checklists result from doing ‘competitive analysis’, just look at what the competitors, and do that too. Development teams have to copy all the software features of the competition, just to keep up. That is mediocrity at its best.

Developing software is not a unique trait. It’s not that hard as it used to be, the lab coats are long since gone. Coding can be outsourced to China or India at a fraction of the cost, as can many other aspects of software development.

Shipping a huge amount of features became relatively cheap. The time of industrialization has come for software development. Lines of code are becoming cheaper every minute. A lot of open source software (‘free software’) now has the same (or more) features as commercial available software.

So, it is not about building a huge amount of features.

It is about building clever software that works really well, in its context. Companies have to build revolutionary, groundbreaking, surprisingly good software to be noticed and successful. It has to be different and fresh, revolutionary perhaps.

How do you do that? Invest in interaction design. Do research to find out who your users really are. Talk to them. The real users.

Learn about them. Find out what they need. Find out what they like, what they don’t like.
Learn where your software becomes part of their lives.

Learn how to improve. Improve your software, and learn more. Make your users happy. Never lose them out of sight.

December 19, 2009 

Daily Scala

Jesse Eichar writes a daily blog about Scala.
“A short daily dose of Scala examples and occasionally explanations”.

Everyday a nice read about Scala. I’ve added it to my newsreader and if you like Scala, you should do too!

http://daily-scala.blogspot.com/


Older Entries »