PaddyCorry
The Subtle Art of avoiding blame and taking responsibility
Writing code is not the only 'real work' in software development teams
Solving complex adaptive problems with rubber ducks
Facilitation skills for Scrum Masters and how to develop them
Snapchat's spectacles still don't make any sense
Serious Scrum weekly digest #50
Serious Scrum weekly digest #49
Serious Scrum weekly digest #48
An update to the definition of Scrum is coming. What can we expect?
Scrum's Connection to Rugby
Has Facebook ruined Silicon Valley?
One Day Every Week Without Tech: The Digital Sabbath
Connecting Facebook and Loneliness
Urinal Video Games on the way
Mono's excellent 'About Us' page: 8-bit Musical Avatars of employees
Kudos to Volkswagen for enforcing the blackberry 'opening hours'. (And here's hoping more companies start to ban internal email!)
Wikipedia's new visual editor
My first job out of college was in a support centre, supporting voice recognition software: an early ancestor of Siri if you like! One weekend without our knowledge, the parent company stuck a prior version of the software onto a free bundle cd that came with a PC magazine in the UK... a great marketing move sure, but the amount of calls we got as a result of that free software was incredible. People can get irate when voice recognition software doesn't work as well as they expect (for a variety of reasons, generally either hardware or accent related!), but with this free version, people really lost the run of themselves altogether... some of the calls we took that week were from some very angry people indeed!
The writer of this article summed up this confusing paradox quite well by offering a refund... for this free item... which was a gift!
Implementing something like this in my organisation would involve a real culture shift, but I can really see the value of the idea. Thanks for that.
NHS abandons £12.7 bn IT project
5 books on the science of being wrong
(This is one of David O'Doherty's 'beefs', towards the end here: http://www.youtube.com/watch?v=GCgYIP-v-e0 )
I'm formerly a COBOL developer, now working with Java. Did anyone else think that his main argument for learning Java could also work for learning COBOL? (substitute COBOL for Java in the quote below)
<quote> It's not going to go away any time soon. There's too much momentum. There's no need to worry. Ever since the launch of Java I've heard that it's going to be gone or unusable tomorrow. History shows that just doesn't happen to popular programming languages.
If you learn Java now, you may still be using it 20 years from now. Or 30. </quote>
When you work in enterprise software, this approach might work on the first project, maybe the second, but eventually a point will arrive where a requirement will take longer to deliver for the simple reason that there are no unit tests. Without unit tests, bugs will be found later in the project life-cycle, possibly even after delivery. If customers have delivered software that is unusable, the fact of delivery becomes a negative pretty quickly..
On the positive side though, the tension between what's essential for the customer, and what developers need to learn to keep their careers alive is an interesting idea, and is something we've been looking recently at where I work. Is it a good idea to introduce a technology just because a programmer feels s/he should learn it? I'm not so sure.
The Mediocrity Principle
Great reference site, thanks.