extracting requirements from flame wars

| No Comments | No TrackBacks
Paul McKenney said he'd been happily ignoring the flame wars about the android platform on the linux kernel mailing lists. He described a parallel of blind penguins building an enclosure for an elephant. Sometimes the blind penguins talk, and achieve concensus, and come up with a good solution.

But with the android stuff they haven't coalesced onto the right way. So he tried to work out some requirements from the android flamewars. He asked the question of why people flame on the mailing lists. There were some answers from teh audience.

You could calm a long flamewar by simply writing the combatants positions in a neutral tone. If it's a short flamewar, you have to already know a lot to help out, because you have only a small amount of time to try and help. If you do try and help, but people may attack you if you try to help.

Paul says if you're going to engage in a flamewar, you need to know what your goals are. If you just want to have fun, you could be just another flamer. You might want to educate yourself, or understand the positions of the flamers. You might want to present a neutral view of the positions, or advocate for a position, or present a neutral view of all positions and even add a critique of each. You may even want to propose a solution designed to meet all participants need.

To do your homework, you should review textbooks, datasheets and technical web sites (sometimes flamewars are because some are misunderstanding some hard facts. Be aware of any axe-grinding that might be taking place.

When you read the flamewar messages, it will probably take you longer to read and analyse than someone posted. He said you need to take notes as you go, to help you build up a picture of what is going on, or what is inside peoples minds (beyond their flameish language). 

He got to talking about power management, and how in the embedded world they work really hard to save power. They work much harder than you do if you are working on servers or laptops. He showed that power efficiency is a system wide issue, not an application specific application. You want to maximise your time that the CPU is switched off.

Paul showed some flames, there was some discussion, and he pointed out some hidden assumptions. So he found it wasn't enough to listen to what people say, you have to strive to understand what they are thinking. To do that you have to understand the technology. People who are strongly opposed, or strongly wedded to a solution are unlikely to welcome use cases, or alternate solutions.

Paul finished by talking about the current state with this flamewar about android wakelocks, what they want, what other people object about, and what might come along in the future as patches to solve some of these problems, or get some of the android patches into mainline.

No TrackBacks

TrackBack URL: http://geoff-blog.cromp.id.au/cgi-bin/movabletype/mt-tb.cgi/129

Leave a comment

About this Entry

This page contains a single entry by Geoff Crompton published on January 27, 2011 5:43 PM.

perl best practices was the previous entry in this blog.

Mark Pesce Friday morning keynote is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.



Powered by Movable Type 4.23-en