SLIM-DataManager
Data Myths
In a post for The Guardian's Datablog, Jonathan Grey explores the rise of data journalism. Data journalism is "a journalistic process based on analyzing and filtering large data sets for the purpose of creating a new story. Data-driven journalism deals with open data that is freely available online and analyzed with open source tools.
Although data is a powerful tool, Grey reminds readers that it's not a silver bullet and counters some commonly held data myths.
Data is not a perfect reflection of the world.
Agile Series Part 2: Stakeholder Satisfaction
When learning something new, people often try to relate the new information back to something they already know in order to help make sense of the new concept or idea. As a psychology major now working in the software world, I’ve found myself relating a lot of what I’m learning back to the psychological theories and concepts I learned in college. Therefore, it is no surprise that upon reading The Twelve Principles of Agile Software, I’ve discovered that many of their principles map to organizational psych concepts.
What's Left Behind When Your Project Is Over
The 2012 Olympics are over and it will be another four years until we can all discuss how much we hate NBC's coverage. Susy Jackson of the Harvard Business Review blog points out in her blog post that while the games of years past have been huge spectacles of debt, the London Olympics have attempted to be "green," in that many of the structures built for the 2012 games will be reused for the 2016 Rio games and other events. Instead of building permanent structures that will be abandoned shortly after the games are over (HBR mentions the " temporary arenas still standing in tatters in Beijing, frogs inhabiting an aban
Taking Responsibility for Quality Data
Thomas C. Redman recently wrote about data quality on the Harvard Business Review blog. In his post, he creates a vignette of an executive who finds an error in data provided by the "Widgets Department" for an important meeting. The executive corrects the error, the meeting is a huge success, and the story ends there. Redman argues that someone should have gone back to the Widgets Department to report the error, not to complain that the error could have ruined the presentation, but rather that it could ruin the next person's presentation.
Data is the New Soil
David McCandless gave a TED talk in July 2010 that focused on pairing data and design to help visualize patterns. In his talk, McCandless takes subsets of data (Facebook status updates, spending, global media panic, etc.) and creates diagrams which expose interesting patterns and trends that you wouldn't think would exist. Although the focus of McCandless' talk was about how to effectively use design to present complex information in a simple way, I was struck by his own claim that data is not the new oil, but rather that data is the new soil. For QSM, this is certainly true!
Demand the (Right) Right Data with SLIM-DataManager
A few weeks ago, Thomas C. Redman posted Demand the (Right) Right Data on the Harvard Business Review blog, about how managers should set the bar higher, in terms of data.
Why are managers so tolerant of poor quality data? One important reason, it seems to me, is that most managers simply don't know that they can expect better! They've dealt with bad data their entire careers and come to accept that checking and rechecking the "facts," fixing errors, and accommodating the uncertainties that using data one doesn't fully trust are the manager's lot in life.
Losses Loom Larger Than Gains
Anyone who has gambled (and lost) knows the sting of losing. In 1979, Daniel Kahneman and Amos Tversky, pioneers in the field of behavioral economics, theorized that losses loom larger than gains; essentially, a person who loses $100 loses more satisfaction that what is gained by someone who wins $100. Behavioral economics weaves psychology and economics together to map the irrational man, the foil of economics' rational man.
How can I leverage this theory for software development?
According to the QSM IT Software Almanac (2006), worst in class projects took 5.6 times as long to complete and used roughly 15 times as much effort with a median team size of 17, and were less likely to track defects.