The ACM (Association for Computing Machinery) are celebrating their 60th anniversary! Happy Birthday! As part of that celebration their May 2007 Issue is free for download.
Quite a few good articles in there. Enjoy!
5/26/07
Here we go again - Why I do not care about JavaFx or Silverlight
(and why Tim Berners-Lee deserves a Nobel prize)
With all the publicity and attention around Web 2.0 these days and RIAs (Rich Internet Applications) it's easy to forget why the web browser and HTML were such a revolution. There's such a buzz now about these new RIA platforms, JavaFX and Silverlight, the open sourcing of Adobe's Flex SDK etc. that it's easy to ignore just how lucky we are.
All I can say is "Here we go again".
Back in the old days (all of 12 years ago i.e. pre-1995) most UIs used proprietary and complex protocols (e.g. CORBA, TCP Sockets) to talk to a Middle-Tier (if it had one), or more often we had simple two-tier applications with the user interface inter-mixing presentation and application code in some language like Powerbuilder.
The problem back then was predominantly one of choice - that is too much choice - too many ways to build UIs and too many ways to inter-operate. Now normally I'm a person who loves choice and abhors a monopoly but in this case choice was a part of the problem (plus the fact that the choices were pretty poor). I didn't then, and don't now really have the time to compare and contrast the different methodologies - I've got a date to hit, a team to get going and functionality to deliver.
With so much choice standardization was impossible as each company fought to protect it's turf. Usability of these user interfaces was also a joke!
HTML and Mosaic from the University of Illinois Urbana-Champaign then came along and the web as we know it was born.
As a consultant who was, at the time, porting Mainframe Green-screens to Powerbuilder, moving to the Web and it's technologies changed my life as a developer for the better. A standard set of simple but powerful technologies (HTML markup and HTTP protocol) was such a great user interface (OK with CSS and Javascript added in).
So in 1995 and on the game had now changed - as long as your user interface code could produce HTML somehow (e.g. ASP, JSP, Servlet etc.) you could drop all this knowledge of proprietary protocols and tools - you didn't have to worry about deployment and myriad other details that could blow-up on the client side.
The end-user (on Windows, Mac or whatever) had a browser - you send HTML,CSS, Javascript. DONE!
Tim Berners-Lee deserves ongoing recognition for the mind-boggling revolution of his invention. Think about pre-1995 - no Google, no Hotmail, no Blogs, no iTunes. Our children and grand-children hopefully will know his name along with those luminaries of the Renaissance - perhaps up there with Gutenberg.
Yes there were and are cross-browser compatibility issues with HTML, CSS and Javascript (there is no free lunch).
But as of 2007 the Web is the most ubiquitous computing platform ever. Let me rephrase that and emphasize for those at Sun, Microsoft and Adobe who can't hear it.
THE WEB IS THE MOST UBIQUITOUS COMPUTING PLATFORM ON THE PLANET . . . EVER!
Jeff Atwood wrote a great blog article recently entitled "Javascript: the lingua franca of the Web" - and he said "It's time we learned to accept and embrace JavaScript rather than blindly fighting it" and "JavaScript remains an excellent choice for rich internet application development". I completely agree.
So right now we've got this nigh-on universal platform - if you want to make Web UIs richer then let's get (force) Microsoft, Sun and whoever else in a room and add capabilities to it for example "Push" technology in particular - but check out Comet.
Oh and while we're at it help reduce the threat of cross-site scripting, SQL injection etc. somehow - the same way Java GC reduces the risk of buffer overflows. Why don't they figure it out so all of us can forget having to worry about it?
They can have new tags, additional Javascript functionality and go back then give us IE8 and Firefox 3.0 support it and let's move on! (I know it's not as easy as that but . . . . )
Ok enough ranting and raving. Yes we want User Interfaces to be richer, but how does having so many RIA options really help me ? Yes in five years we'll come to agreement on which one is best but for now I'm sticking with Javascript for it's ubiquity and if I have a UI that needs to do some heavy lifting then guess what - it's .Net on Windows.
Dear Sun, help me fix my problems today - I don't need another UI technology / language - Swing, AWT, JSP, Servlet, JSF, Applets - sheesh! Enough! Look at Google's Web Toolkit - make it easier for me to write Web apps or you could always just focus on fixing Swing.
p.s. For some related comments see also another blogger's post Silly Season which is a little more blunt but rightly so.
With all the publicity and attention around Web 2.0 these days and RIAs (Rich Internet Applications) it's easy to forget why the web browser and HTML were such a revolution. There's such a buzz now about these new RIA platforms, JavaFX and Silverlight, the open sourcing of Adobe's Flex SDK etc. that it's easy to ignore just how lucky we are.
All I can say is "Here we go again".
Back in the old days (all of 12 years ago i.e. pre-1995) most UIs used proprietary and complex protocols (e.g. CORBA, TCP Sockets) to talk to a Middle-Tier (if it had one), or more often we had simple two-tier applications with the user interface inter-mixing presentation and application code in some language like Powerbuilder.
The problem back then was predominantly one of choice - that is too much choice - too many ways to build UIs and too many ways to inter-operate. Now normally I'm a person who loves choice and abhors a monopoly but in this case choice was a part of the problem (plus the fact that the choices were pretty poor). I didn't then, and don't now really have the time to compare and contrast the different methodologies - I've got a date to hit, a team to get going and functionality to deliver.
With so much choice standardization was impossible as each company fought to protect it's turf. Usability of these user interfaces was also a joke!
HTML and Mosaic from the University of Illinois Urbana-Champaign then came along and the web as we know it was born.
As a consultant who was, at the time, porting Mainframe Green-screens to Powerbuilder, moving to the Web and it's technologies changed my life as a developer for the better. A standard set of simple but powerful technologies (HTML markup and HTTP protocol) was such a great user interface (OK with CSS and Javascript added in).
So in 1995 and on the game had now changed - as long as your user interface code could produce HTML somehow (e.g. ASP, JSP, Servlet etc.) you could drop all this knowledge of proprietary protocols and tools - you didn't have to worry about deployment and myriad other details that could blow-up on the client side.
The end-user (on Windows, Mac or whatever) had a browser - you send HTML,CSS, Javascript. DONE!
Tim Berners-Lee deserves ongoing recognition for the mind-boggling revolution of his invention. Think about pre-1995 - no Google, no Hotmail, no Blogs, no iTunes. Our children and grand-children hopefully will know his name along with those luminaries of the Renaissance - perhaps up there with Gutenberg.
Yes there were and are cross-browser compatibility issues with HTML, CSS and Javascript (there is no free lunch).
But as of 2007 the Web is the most ubiquitous computing platform ever. Let me rephrase that and emphasize for those at Sun, Microsoft and Adobe who can't hear it.
THE WEB IS THE MOST UBIQUITOUS COMPUTING PLATFORM ON THE PLANET . . . EVER!
Jeff Atwood wrote a great blog article recently entitled "Javascript: the lingua franca of the Web" - and he said "It's time we learned to accept and embrace JavaScript rather than blindly fighting it" and "JavaScript remains an excellent choice for rich internet application development". I completely agree.
So right now we've got this nigh-on universal platform - if you want to make Web UIs richer then let's get (force) Microsoft, Sun and whoever else in a room and add capabilities to it for example "Push" technology in particular - but check out Comet.
Oh and while we're at it help reduce the threat of cross-site scripting, SQL injection etc. somehow - the same way Java GC reduces the risk of buffer overflows. Why don't they figure it out so all of us can forget having to worry about it?
They can have new tags, additional Javascript functionality and go back then give us IE8 and Firefox 3.0 support it and let's move on! (I know it's not as easy as that but . . . . )
Ok enough ranting and raving. Yes we want User Interfaces to be richer, but how does having so many RIA options really help me ? Yes in five years we'll come to agreement on which one is best but for now I'm sticking with Javascript for it's ubiquity and if I have a UI that needs to do some heavy lifting then guess what - it's .Net on Windows.
Dear Sun, help me fix my problems today - I don't need another UI technology / language - Swing, AWT, JSP, Servlet, JSF, Applets - sheesh! Enough! Look at Google's Web Toolkit - make it easier for me to write Web apps or you could always just focus on fixing Swing.
p.s. For some related comments see also another blogger's post Silly Season which is a little more blunt but rightly so.
5/14/07
10 things I wished I had known starting out in Software
It's been a long hard road to learning these and so I figure I might as well pass it on . . .
10) Automate Everything
As a developer with looming deadlines there's a tendency to accept repetitious tasks (who has time to automate?) but these actions can suck up so much time and effort that it's almost always worth the effort especially if the tasks are repetitive across a team.
So automate EVERYTHING! Your build, your deployment, your smoke test, your unit tests, your regression tests, your monitoring etc. Learn great tools like Ant and Perl which will form the basis of many automation scripts.
9) Remember Microsoft vs. Apple - can you get rich and be right?
Do you want to be rich or right? The application with the least bugs, best usability and most features usually isn't the one that wins. It should - but this isn't about "should" it's about hard-learned lessons in the real world.
Sales and marketing have much more to do with success than how cool your technology is. Apple has the great design, great usability and lots of the "right stuff" but Microsoft has made more millionaires than Apple (although Apple's stock has risen a lot lately and MSFT has flatlined see here).
8) Your user's world is much bigger than your application
Your application or piece of software means all the world to you - but to your users it's just a tool. Let your user do what they need to and other than that stay out of the way. They don't care if you use Ajax and JSON or DWR, they don't mind that SOAP sucks/rules and REST rules/sucks - they just need to update some data and get back to the other million things they do every day.
7) Don't make your users think!
In the same vein as #8 - go easy on your users in terms of usability. Some web sites are so easy and intuitive to use you don't really realize it. When you notice the usability of a site it's more often than not bad news (unless it's in comparison to something worse). Learn about usability - use paradigms that users are likely to know already e.g. Windows explorer (for hierarchies of data), Microsoft Excel (for grids) etc.
Check out this great snippet from David Platt or this link! Your tool is a means to an end not the end itself!
6) Skill in Communication is the key to career advancement
The most successful developers are the one's who can communicate well - in the written form as well as in the meeting room. How can management know what is happening if you can't communicate it to them? And if you can communicate and do it really well, would you like a secretary with that corner office?
5) Developers are the worst testers
We think super-rationally and in a very linear fashion - that's the way we need to be to help write code for our dumb computers - users are just everyday people - irrational, forgetful and they think in different "nonlinear" ways - in other words, they are the normal ones - we're the weirdos! :-)
The best testers of all are those people who know NOTHING about your application or what it is supposed to do - you'll be amazed at what they'll try to do, where they'll click and what they ignore!
4) User involvement is the biggest single factor in product success
What do your users want? It's not what *you* want! Watch, listen and learn from them.
3) In the end it's ALL about Sales and Marketing
MBAs study sales and marketing for a good reason - these two activities drive revenue almost without regard to the quality of your product. Crazy eh? Why do people still buy BMWs when Toyota's are a much cheaper and more reliable? The BMW brand, the appeal to the ego, keeping up with the Jones's etc.
Why must your application be Ajax, Web 2.0 and SOA compliant? Because that's what CIOs want - perhaps not what they need, but they want it because ComputerWorld says they should or their CEO heard about it on CNN! It promises to be the next silver bullet (like EJB was, like .Net was, like the Web was etc.) so we need it now!
Can you do it? Doesn't matter, most of the time they can't tell. That's how most Consulting firms make their money - they sell the deal and the peons have to figure out how to make it work. By the time they realize, you've got their money and are on to the next job. This isn't something to be proud of but it's the way the world works. But the point - it's all about Sales and Marketing.
And for you the developer, you need to be able to sell and market yourself - What do you know? What can you do? What problems did you help solve? How flexible can you be to new demands? Get the word out on that and you'll be in good shape - you don't need to be a shameless self-promoter but you can't expect people to be psychic. Offer help, ask for help, learn from others - in the interaction alone people will learn what you're about.
2) Business operates fine on the 80/20 rule (a.k.a. the Pareto Principle)
So many developers are Type-A personalities who must get an "A+" at all times, but business doesn't operate like school - you don't need to get 90% of your application correct. There's no one single exam - it's an every day thing. You can't cram at the end either. You can get the majority of the benefit of effort from focusing on a select few of the most commonly used parts of your application.
Another instance of this is that the majority of users will be affected by a minority of bugs you find in QA etc.
The hard part is identifying the right 20% to address.
Also if you shoot for being 100% bug free your competition will eat you alive as they'll be first to market - yes with bugs and perhaps poor usability but with regular releases they can release patches/fixes and upgrades. People's expectations are sadly still pretty low for software! You don't have to be the one to change it - just be receptive to feedback, accommodate reasonable requests and they'll love you for that alone.
1) Perception is reality
This probably subsumes points #2, #3 and #4 above - again your "grade" isn't driven by some rational multiple-choice, right or wrong solution. You can deliver a not-so-great application but if you have strong relationships with your users and those controlling the purse strings you'll be in a better position than a "perfect" application but no relationship.
10) Automate Everything
As a developer with looming deadlines there's a tendency to accept repetitious tasks (who has time to automate?) but these actions can suck up so much time and effort that it's almost always worth the effort especially if the tasks are repetitive across a team.
So automate EVERYTHING! Your build, your deployment, your smoke test, your unit tests, your regression tests, your monitoring etc. Learn great tools like Ant and Perl which will form the basis of many automation scripts.
9) Remember Microsoft vs. Apple - can you get rich and be right?
Do you want to be rich or right? The application with the least bugs, best usability and most features usually isn't the one that wins. It should - but this isn't about "should" it's about hard-learned lessons in the real world.
Sales and marketing have much more to do with success than how cool your technology is. Apple has the great design, great usability and lots of the "right stuff" but Microsoft has made more millionaires than Apple (although Apple's stock has risen a lot lately and MSFT has flatlined see here).
8) Your user's world is much bigger than your application
Your application or piece of software means all the world to you - but to your users it's just a tool. Let your user do what they need to and other than that stay out of the way. They don't care if you use Ajax and JSON or DWR, they don't mind that SOAP sucks/rules and REST rules/sucks - they just need to update some data and get back to the other million things they do every day.
7) Don't make your users think!
In the same vein as #8 - go easy on your users in terms of usability. Some web sites are so easy and intuitive to use you don't really realize it. When you notice the usability of a site it's more often than not bad news (unless it's in comparison to something worse). Learn about usability - use paradigms that users are likely to know already e.g. Windows explorer (for hierarchies of data), Microsoft Excel (for grids) etc.
Check out this great snippet from David Platt or this link! Your tool is a means to an end not the end itself!
6) Skill in Communication is the key to career advancement
The most successful developers are the one's who can communicate well - in the written form as well as in the meeting room. How can management know what is happening if you can't communicate it to them? And if you can communicate and do it really well, would you like a secretary with that corner office?
5) Developers are the worst testers
We think super-rationally and in a very linear fashion - that's the way we need to be to help write code for our dumb computers - users are just everyday people - irrational, forgetful and they think in different "nonlinear" ways - in other words, they are the normal ones - we're the weirdos! :-)
The best testers of all are those people who know NOTHING about your application or what it is supposed to do - you'll be amazed at what they'll try to do, where they'll click and what they ignore!
4) User involvement is the biggest single factor in product success
What do your users want? It's not what *you* want! Watch, listen and learn from them.
3) In the end it's ALL about Sales and Marketing
MBAs study sales and marketing for a good reason - these two activities drive revenue almost without regard to the quality of your product. Crazy eh? Why do people still buy BMWs when Toyota's are a much cheaper and more reliable? The BMW brand, the appeal to the ego, keeping up with the Jones's etc.
Why must your application be Ajax, Web 2.0 and SOA compliant? Because that's what CIOs want - perhaps not what they need, but they want it because ComputerWorld says they should or their CEO heard about it on CNN! It promises to be the next silver bullet (like EJB was, like .Net was, like the Web was etc.) so we need it now!
Can you do it? Doesn't matter, most of the time they can't tell. That's how most Consulting firms make their money - they sell the deal and the peons have to figure out how to make it work. By the time they realize, you've got their money and are on to the next job. This isn't something to be proud of but it's the way the world works. But the point - it's all about Sales and Marketing.
And for you the developer, you need to be able to sell and market yourself - What do you know? What can you do? What problems did you help solve? How flexible can you be to new demands? Get the word out on that and you'll be in good shape - you don't need to be a shameless self-promoter but you can't expect people to be psychic. Offer help, ask for help, learn from others - in the interaction alone people will learn what you're about.
2) Business operates fine on the 80/20 rule (a.k.a. the Pareto Principle)
So many developers are Type-A personalities who must get an "A+" at all times, but business doesn't operate like school - you don't need to get 90% of your application correct. There's no one single exam - it's an every day thing. You can't cram at the end either. You can get the majority of the benefit of effort from focusing on a select few of the most commonly used parts of your application.
Another instance of this is that the majority of users will be affected by a minority of bugs you find in QA etc.
The hard part is identifying the right 20% to address.
Also if you shoot for being 100% bug free your competition will eat you alive as they'll be first to market - yes with bugs and perhaps poor usability but with regular releases they can release patches/fixes and upgrades. People's expectations are sadly still pretty low for software! You don't have to be the one to change it - just be receptive to feedback, accommodate reasonable requests and they'll love you for that alone.
1) Perception is reality
This probably subsumes points #2, #3 and #4 above - again your "grade" isn't driven by some rational multiple-choice, right or wrong solution. You can deliver a not-so-great application but if you have strong relationships with your users and those controlling the purse strings you'll be in a better position than a "perfect" application but no relationship.
5/11/07
Document your application with a Wiki? No thanks!
Let me start off by saying that some people find these effective and so that's fine - to each his own. But frankly I really dislike Wikis especially in the way they are used as a central place for developers on the same team to document things related to their application.
From a technical point Wikis are great - a place where everyone and anyone can make updates and Wikipedia is wonderful (but there are good moderators in place - at least most of the time).
The problem is when the average developer gets a hold of it - and there's no real moderation - it becomes a Joycean stream of consciousness piece that, while it makes sense to the writer, isn't worth much to the guy or gal reading it and trying to get some stuff done.
The key, I guess, is structure - think about the kinds of papers etc. you would write in school or college for assignments - structure is key - a rambling set of paragraphs might work well in English Lit class but for us Tech geeks . . . . . . ouch! Think about recipes for cooking - a step-by-step guide with structure is a lot easier to follow than a big hunk of text.
Another issue is the dissolution of authorship - what's that? Well imagine a case where I read something on the Wiki that's confusing. So now I need to contact the author to find out what they meant by that - but who do I call/email?
So here are some guidelines for what helps me navigate a Wiki or what makes a Wiki good.
1) Use Headings
Delineate sections with headings and sub-headings e.g.
A) How to Install
B) How to run a quick scenario
C) How to create your own scenario
D) Troubleshooting guide
E) FAQ
2) Use Hyperlinks only to link away from your site
Such as for document repositories, good online articles etc. - not for links within the site as they start to diminish any "structure" to the Wiki.
3) Use breadcrumbs
They help people know where they are - for one reason or another people tend to think in structured and ordered ways and have cognitive limits to how much stuff they can keep in memory (where was I three clicks ago?)
4) Use bullets
They tend to help you reduce the amount of text you are writing and just focus on getting simple points across. Long paragraphs are arduous to read for those of us fighting the fight against information overload.
5) Iterate and improve
Try not to cram too much on one page - refactor! :-)
Remove redundant information.
6) Use Pictures
They provide less opportunity for confusion and communicate a lot with relatively little effort.
7) Follow the leader
If in doubt look at Wikipedia for ideas - especially they have quite a bit of usage of
- Good headings
- Good mix of bullets and plain old text paragraphs.
Check out Wikipedia's Style Guide
8) Enforcement
Small group of moderators with sense of 'ownership'. Someone usually has to enforce the structure.
9) Newbie test
If the newbie can't navigate around with ease you've got a problem to fix.
So getting back to why I don't like Wikis (at least insofar as their usage for communicating across development teams) -they don't provide easy ways to give structure to information that more often than not, at least in the world of software, needs structure.
Software is such a complex and abstract thing at times we need help in minimizing the cognitive overload inherent in the abstract concepts therein.
And then again maybe it's just me :-) Or maybe not . . .
"It seems to me that wikis are designed for people who don't really care whether their informtion[sic] is organized or accessible."
http://mamamusings.net/archives/2003/08/24/why_i_still_hate_wikis.php
"Wikis are the easiest way to create awful documentation"
http://www.alittlemadness.com/?p=5
" I realized why I hate editing wikis so much: for the same reason that no one speaks Esperanto."
http://www.snout.org/hotsheet/2005/12/i-hate-wikis.html
"Wikis dissolve authorship"
http://www.cjung.info/wordpress/?p=96
And now this one is really funny http://www.reddnet.net/Scribbles/682.aspx
Especially their response to the common refrain "Did you check the Wiki?".
From a technical point Wikis are great - a place where everyone and anyone can make updates and Wikipedia is wonderful (but there are good moderators in place - at least most of the time).
The problem is when the average developer gets a hold of it - and there's no real moderation - it becomes a Joycean stream of consciousness piece that, while it makes sense to the writer, isn't worth much to the guy or gal reading it and trying to get some stuff done.
The key, I guess, is structure - think about the kinds of papers etc. you would write in school or college for assignments - structure is key - a rambling set of paragraphs might work well in English Lit class but for us Tech geeks . . . . . . ouch! Think about recipes for cooking - a step-by-step guide with structure is a lot easier to follow than a big hunk of text.
Another issue is the dissolution of authorship - what's that? Well imagine a case where I read something on the Wiki that's confusing. So now I need to contact the author to find out what they meant by that - but who do I call/email?
So here are some guidelines for what helps me navigate a Wiki or what makes a Wiki good.
1) Use Headings
Delineate sections with headings and sub-headings e.g.
A) How to Install
B) How to run a quick scenario
C) How to create your own scenario
D) Troubleshooting guide
E) FAQ
2) Use Hyperlinks only to link away from your site
Such as for document repositories, good online articles etc. - not for links within the site as they start to diminish any "structure" to the Wiki.
3) Use breadcrumbs
They help people know where they are - for one reason or another people tend to think in structured and ordered ways and have cognitive limits to how much stuff they can keep in memory (where was I three clicks ago?)
4) Use bullets
They tend to help you reduce the amount of text you are writing and just focus on getting simple points across. Long paragraphs are arduous to read for those of us fighting the fight against information overload.
5) Iterate and improve
Try not to cram too much on one page - refactor! :-)
Remove redundant information.
6) Use Pictures
They provide less opportunity for confusion and communicate a lot with relatively little effort.
7) Follow the leader
If in doubt look at Wikipedia for ideas - especially they have quite a bit of usage of
- Good headings
- Good mix of bullets and plain old text paragraphs.
Check out Wikipedia's Style Guide
8) Enforcement
Small group of moderators with sense of 'ownership'. Someone usually has to enforce the structure.
9) Newbie test
If the newbie can't navigate around with ease you've got a problem to fix.
So getting back to why I don't like Wikis (at least insofar as their usage for communicating across development teams) -they don't provide easy ways to give structure to information that more often than not, at least in the world of software, needs structure.
Software is such a complex and abstract thing at times we need help in minimizing the cognitive overload inherent in the abstract concepts therein.
And then again maybe it's just me :-) Or maybe not . . .
"It seems to me that wikis are designed for people who don't really care whether their informtion[sic] is organized or accessible."
http://mamamusings.net/archives/2003/08/24/why_i_still_hate_wikis.php
"Wikis are the easiest way to create awful documentation"
http://www.alittlemadness.com/?p=5
" I realized why I hate editing wikis so much: for the same reason that no one speaks Esperanto."
http://www.snout.org/hotsheet/2005/12/i-hate-wikis.html
"Wikis dissolve authorship"
http://www.cjung.info/wordpress/?p=96
And now this one is really funny http://www.reddnet.net/Scribbles/682.aspx
Especially their response to the common refrain "Did you check the Wiki?".
5/8/07
Bugs and Grade Inflation
or "Why are 90% of my bugs High priority!?!?!?"
Here's something I've seen at every place I've worked in my decade of industry experience and something I experience most days. It's a fairly tough problem but I've never really seen people talk about it or try to address adequately:
Why, when people create bug reports, are the bugs almost always High priority?
Given a scale of 1 to 5 or just categories of "Low", "Medium", "High" the distribution usually is clustered around the top end? In fact I've seen people add "Very High" and "Ultra High" as priorities and yet still 80-90% of all the bugs are "Very High" or above, and any bug that is medium or low priority will almost certainly be ignored.
But back to the question of "Why?" - well I guess it makes sense in that to the person testing, the bug probably impacts them and what they are trying to achieve with the app, and so to them it is a high priority. But that is not helpful to the developer who now has a list of say 20+ bugs, 18 of which are high priority and she probably has a number of people clamoring for all of those to be fixed right now. Oh and they've got new development due by the end of the week too?
I've seen a few proposed solutions in my time:
1) Use a priority and a severity
So in this case a high severity could be an app crash, but it's low priority as it might be an unusual or uncommon use case. Unfortunately that creates some confusion as often a high severity bug usually is a sign of a more serious bug that when found WILL be a high priority.
The correlation between the two measures is pretty high and, at least when I got bugs with very different priority/severity ratings I had to dig into them as most times one or the other measure was off. Either way you, or at least someone, has to spend (valuable) time to dig into the issue and find out what's what :-(
2) Have the team lead assign or update the priority
Unfortunately this approach often annoys the person opening the bug (remember they probably set it to "High" and so any change is usually a downgrade). So it works fine but the Team lead takes quite a bit of heat (don't ask how I know just trust me that I do!)
Another issue that results from making so many bugs high priority is that, by focusing solely on the high priority bugs, the number of medium and low priority bugs mounts up - and sometimes some of those are mislabeled. When you dig into them the might really be high priority - or at least higher priority for someone else you know!
Effectively though, from the developer's point of view they've really just got a prioritized queue of work and that priority can be set by any number of people (team leads, architects, users, product managers, project managers, higher management, tech support, etc.). But the skewness in the distribution is what's really the awkward part here.
I'd propose a voting mechanism where each interested party votes for priority, but again some will vote high (as it's in their interest) and some will vote low not because the bug is low priority per se but just to decrease the average priority and perhaps boost their bugs' priorities! And as always some won't vote at all and yet still complain! Is something akin to Digg the answer?
Maybe we could make the voting of others invisible to everyone except the developer? Then you'll have the interested party probably trying to figure out why the devloper is not working on some issue.
Have you seen any good solutions to this? Is there some idealized distribution of bugs across the priority categories to aim for? Is the best solution just some kind of benevolent dictator like many Open Source projects use? Is there some "fair" scheme (or at least a "least unfair" scheme)?
Or is this kind of problem in the same camp of problems where there is no perfect answer? Similar to that quote from Churchill about democracy:
"It has been said that democracy is the worst form of government except all the others that have been tried" Link
meaning there are no "always correct" answers to this problem?
Here's something I've seen at every place I've worked in my decade of industry experience and something I experience most days. It's a fairly tough problem but I've never really seen people talk about it or try to address adequately:
Why, when people create bug reports, are the bugs almost always High priority?
Given a scale of 1 to 5 or just categories of "Low", "Medium", "High" the distribution usually is clustered around the top end? In fact I've seen people add "Very High" and "Ultra High" as priorities and yet still 80-90% of all the bugs are "Very High" or above, and any bug that is medium or low priority will almost certainly be ignored.
But back to the question of "Why?" - well I guess it makes sense in that to the person testing, the bug probably impacts them and what they are trying to achieve with the app, and so to them it is a high priority. But that is not helpful to the developer who now has a list of say 20+ bugs, 18 of which are high priority and she probably has a number of people clamoring for all of those to be fixed right now. Oh and they've got new development due by the end of the week too?
I've seen a few proposed solutions in my time:
1) Use a priority and a severity
So in this case a high severity could be an app crash, but it's low priority as it might be an unusual or uncommon use case. Unfortunately that creates some confusion as often a high severity bug usually is a sign of a more serious bug that when found WILL be a high priority.
The correlation between the two measures is pretty high and, at least when I got bugs with very different priority/severity ratings I had to dig into them as most times one or the other measure was off. Either way you, or at least someone, has to spend (valuable) time to dig into the issue and find out what's what :-(
2) Have the team lead assign or update the priority
Unfortunately this approach often annoys the person opening the bug (remember they probably set it to "High" and so any change is usually a downgrade). So it works fine but the Team lead takes quite a bit of heat (don't ask how I know just trust me that I do!)
Another issue that results from making so many bugs high priority is that, by focusing solely on the high priority bugs, the number of medium and low priority bugs mounts up - and sometimes some of those are mislabeled. When you dig into them the might really be high priority - or at least higher priority for someone else you know!
Effectively though, from the developer's point of view they've really just got a prioritized queue of work and that priority can be set by any number of people (team leads, architects, users, product managers, project managers, higher management, tech support, etc.). But the skewness in the distribution is what's really the awkward part here.
I'd propose a voting mechanism where each interested party votes for priority, but again some will vote high (as it's in their interest) and some will vote low not because the bug is low priority per se but just to decrease the average priority and perhaps boost their bugs' priorities! And as always some won't vote at all and yet still complain! Is something akin to Digg the answer?
Maybe we could make the voting of others invisible to everyone except the developer? Then you'll have the interested party probably trying to figure out why the devloper is not working on some issue.
Have you seen any good solutions to this? Is there some idealized distribution of bugs across the priority categories to aim for? Is the best solution just some kind of benevolent dictator like many Open Source projects use? Is there some "fair" scheme (or at least a "least unfair" scheme)?
Or is this kind of problem in the same camp of problems where there is no perfect answer? Similar to that quote from Churchill about democracy:
"It has been said that democracy is the worst form of government except all the others that have been tried" Link
meaning there are no "always correct" answers to this problem?
Subscribe to:
Posts (Atom)