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.
Agile Craftsmanship 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.
Software Craftsmanship So what is software craftsmanship? A better metaphor: In a very simplistic way, we can say that software craftsmanship is a better metaphor for software development than software engineering, as I wrote in a previous post. Software craftsmanship sees software as a craft and compares software developers to the medieval blacksmiths. Wikipedia Definition: is an approach to software development that emphasizes the coding skills of the software developers themselves. I personally don't like too much the Wikipedia's definition. A more personal definition: Software craftsmanship is a long journey to mastery. A software craftsman cares and is proud of his or her work and is extremely professional and pragmatic when it comes to its implementation. The Software Craftsmanship Movement In the manifesto, the essence of the software craftsmanship is capture in its subtitle: Raising the bar. The values of the Software Craftsmanship Movement Not only working software, but also well-crafted software
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.
Robert Cecil Martin Robert Cecil Martin (born 5 December 1952), known colloquially as "Uncle Bob", is an American software consultant and author. Martin has been a software professional since 1970 and an international software consultant since 1990. In 2001, he initiated the meeting of the group that created agile software development from extreme programming techniques. He is also a leading member of the software craftsmanship movement. From 1996 to 1999 he was the editor-in-chief of the C++ Report. Bibliography Designing Object-Oriented C++ Applications using the Booch Method. See also References External links Agile Manifesto Signatories Personal Sites Talks Clean Coder
Inside the Mind of Jeff Bezos Manifesto for Agile Software Development 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