Punishment driven development I'm a big fan of agile development. One of the key concepts that I like the most is story point estimation. The best suggestion I ever heard was to estimate the size of your stories in terms of gummy bears (at which point you can come up with possibly one of the best units of progress measurement, gummy bears / iteration), thereby making sure that nobody gets the impression that you're actually quoting any sort of real unit of time. The exact opposite of this is trying to estimate stories in an agile project in terms of hours. All too often, even though these realistically are no more than "ideal hours", they are taken literally by everybody and if a developer doesn't manage to "burn down" 80 hours of development per week, they risk being told to either work harder or estimate better (it's often left ambiguous which solution is preferable), leading to what can possibly best be described as punishment driven development.
Inside the Mind of Jeff Bezos Agile Ruined My Life I read the reply to my comment on a popular hacker board with sadness: (disclaimer: Agile consultants ruined the software group I work in.)Making good software is hard, and anyone claiming to have a magical process that guarantees good software is selling snake oil. I can appreciate your wanting to make a buck, but would also seriously appreciate it if you could find some other industry besides software development to go screw up Reminded me of an email I received back in May: [We] started working on [agile technique X] when [author]‘s [famous book] was just a draft. I’ve had many such conversations over the years.There are some seriously pissed off people about Agile out there. The easy answer — and the answer most agile-lovers would give — is that these folks are simply non-hackers. I don’t accept that. And the thing is, it’s not just the people who are being trained. So it’s time to get honest. Here are the problems I see and hear about: What’s Iterative Development? What’s Scrum? Nada.
10 Mistakes That Software Team Leads Make Roy “Ten Mistakes” (as I shall now call it because I’m too lazy to keep typing the whole title), was a talk by Roy Osherove which I went to at Skills Matter. He basically takes us through ten common mistakes he sees team leaders make, and offers some solutions to them. He also looks like Adam Sandler, I kid you not. Adam Sandler Here’s Adam, doing some funny acting, or something. Roy Osherove Here’s Roy delivering a piece to camera… Adam Roy started us off by talking about a number of questions that team leaders might have. How do I convince my team to do XWhat do I do with the bad apple in my team? He said that these were all questions that haunted him for years, and in the rest of the talk he goes on to explain how to answer them. So, we then moved on to the first of the Ten Mistakes… #1 Not Recognising Team Maturity This was a good place to start because much of the talk referred back to the “maturity level” of the team. ChaosLearningSelf-Leading Chaos
Agile Intifada This blog post was inspired by a link my friend sent me titled “Agile Ruined My Life” as well as a conversation with my friends/co-workers and just wanting to clear up a few things about my previous “Agile Dilemma” post. Some of this is taken verbatim from an email exchange between myself and a few friends I greatly respect. I agree/like agile in theory and practice. I wrote the Agile Dilemma post mostly while I was letting off steam about computer science itself becoming extinct in lieu of a bunch of consultants pushing agile and TDD 90% of the time without teaching people how to actually design and write good software. Now, there are those that go even as far as saying that non-TDD written code is “stone age” or that programmers not practicing agile, TDD, pair-programming and all the other process crap are not “good” programmers or shouldn’t be programming. Writing tests is not innovative, it’s been around for decades. Agile is also not innovative. So let’s get back to basics.
Should You Ship This Code Before Reducing Technical Debt?! Technical debt is usually perceived as a measure of expediency. Source: JulesH, Wikipedia, A control flow graph of a simple function You borrow a little (time) with the intent of paying it back as soon as possible. To quote Ward Cunnigham: Shipping first time code is like going into debt. As is often the case with financial debt, technical debt accrues with compound interest. The Figure below, taken from An Objective Measure of Code Quality by Mark Dixon, answers the question with respect to one important component of technical debt – cyclomatic complexity. To answer the question cited above – Should You Ship This Software Before Reducing Technical Debt?! The economics of defect removal clearly favor early defect removal over late defect removal. If you decide to postpone the release date until the technical debt has been reduced, you can apply yourself to technical debt reduction in a biggest-bang-for-the-buck manner.
Iterationless Development – the latest New New Thing Thanks to the Lean Startup movement, Iterationless Development and Continuous Deployment have become the New New Thing in software development methods. Apparently this has gone so far that “there are venture firms in Silicon Valley that won’t even fund a company unless they employ Lean startup methodologies”. Although most of us don’t work in a Web 2.0 social media startup, or anything like one, it’s important to cut through the hype and see what we can learn from these ideas. One of the most comprehensive descriptions I’ve seen so far of Iterationless Development is a (good, but buzzword-heavy) presentation by Erik Huddleston that explains how development is done at Dachis Group, which builds online social communities. Work is managed using Kanban WIP limits and queues. Developers create tests for each change or fix up front. Death to Time Boxing In a separate blog post, he talks about the death of iterations. Risk is managed in the same tactical, short-sighted way.
Rollbacks and Other Deployment Myths I came across an interesting post today via HN. I’m surprised (only moderately) that I missed it the first time around since this is right up my alley: Why are you still deploying overnight? I thought this post was particularly apropos for several reasons. I just got back from DevOpsDays EU AND I’m currently in the process of refactoring our deploy process. This post was authored by John E. I’m breaking this up into two parts since it’s a big topic. Myths, Lies and other bullshit Before I go any further, we should probably clear up a few things. Understand, first and foremost, that I’m no spring chicken in this business. Also, this is not a “tell you what to do” post. So what are some of the myths and other crap people like to pull out when having these discussions? Change == RiskDeploys are riskyRollbacksNothing failsSLAs There’s plenty more but these are some of the key ones that I hear. Change is change The idea that change has a risk associated with it is entirely a human construct.
Deploy ALL the Things - Deployment Myths Part 2 This is part 2 in a post on deployment strategies. The previous post is located here This post was authored by John E. Vincent (aka. lusis). Creator of Noah—a lightweight node/service registry inspired by Apache Zookeeper. For more deployment patterns and anti-patterns, chec, out DZone's Continuous Delivery Refcard. My previous post covered some of the annoying excuses and complaints that people like to use when discussing deployments. The risk associated with deploying new code is not in the deploy itself but everything you did up to that point.The way to make deploying new code less risky is to do it more often, not less.Create a culture and environment that enables and encourages small, frequent releases.Everything fails. I want to make one thing perfectly clear. Understanding the role of operations Operations is an interesting word. IT operations traditionally does nothing in that regard. Don’t worry. Technical Debt and Risk Management Testing The key here is baby steps. 10 minute maxim