This is the final part of the Rebooting ALM series. You should also read: Part I: Evolution Part II: Power Part III: Weakness We’ve covered where ALM tools excel, and where they falter. Now, allow me to fantasize about how we can take a leap forward and start solving actual problems for real ALM users (that’s
This is the 3rd part of Rebooting ALM series. You can find the others here: Part I: Evolution Part II: Power Obviously, I wouldn’t call this series “Rebooting ALM” if the tools didn’t have their weaknesses. Let me count the ways. The first problem of ALM tools starts with the customer. The end-user of the system (developers,
Had a great time with at last conference of the year. Here are the slides of the “Rebooting ALM” talk. If you want to read what it’s all about, there’s a post series about it: Part I: Evolution Part II: Power And a few more coming up.
This is the 2nd part in the Rebooting ALM series. Check out the first part “Evolution“, to see how we got here. (See what I did?). The first tool, I think, that started the ALM tool chain, was source control. There were compilers, and some IDEs, but source control systems were solutions for team-work. If
This is the first in a series about Rebooting ALM. I’m going to present this next at Agile Slovenia in a week, don’t miss it. I’ve started thinking about how Application Life Cycle Management has changed over the years. It’s funny, because what’s the first thing they teach you in agile class (I hope)? “Individuals
Had a great time in Edinburgh, and looking forward to getting back next year. Here are the slides.
Unfortunately, I won’t be able to present at DevGeekWeek. But I do have a slide deck I’ve prepared for it. It was supposed to be presented at the Application Life-cycle Managemenet (ALM) track. And since, we’re dealing with experimentation, let’s use the deck for an experiment: Would you like to attend a webinar about this? Let me know
When asked:”What’s the best thing I can do right now to improve my code quality” I always answer: code reviews. A code review is the best bug preventer out there. And even more, I like its older brother better: Pair programming. Because if a code review finds bugs after the fact, working in pairs finds
Something strange is going through TDD land these last couple of weeks. First it was Uncle Bob,with a new TDD theory – making tests pass in a certain order, actually helps incremental design, leading to a better solution. This is a very interesting post, and if he’s right, he might have discovered the cornerstone of
After my last post, I got some feedback, that I didn’t really answer the question in the title. So I’m going to fix that. Roughly speaking, 10% of developers are doing unit testing today (Let’s call them group A). Some 15% have heard or tried (B), and the rest don’t even know it exists (C).