tag:blogger.com,1999:blog-347417022012-01-27T14:03:30.539-04:00Ryan Cooperhttp://www.blogger.com/profile/08635857155555755249noreply@blogger.comBlogger211100tag:blogger.com,1999:blog-34741702.post-74332055772023728952009-06-10T00:58:00.027-03:002009-06-16T16:16:37.664-03:00

This is Part III of a 3 part series detailing common problems with software estimates and some simple ways to handle them. Part I can be found here, and part II can be found here.Unfortunately, most of us software developers are pretty bad at estimation. Is it because we're incompetent? Of course not. It's because coding is creative work, and creative work is unpredictable. Writing software

Ryan Cooperhttp://www.blogger.com/profile/08635857155555755249noreply@blogger.com44tag:blogger.com,1999:blog-34741702.post-56268766199926166182009-06-10T00:58:00.025-03:002009-06-12T01:44:56.081-03:00

This is Part II of a 3 part series detailing common problems with software estimates and some simple ways to handle them. Part I can be found here.Unfortunately, most of us software developers are pretty bad at estimation. Is it because we're incompetent? Of course not. It's because coding is creative work, and creative work is unpredictable. Writing software is not like working on an

Ryan Cooperhttp://www.blogger.com/profile/08635857155555755249noreply@blogger.com0tag:blogger.com,1999:blog-34741702.post-36284964615676243512009-06-04T18:10:00.020-03:002009-06-10T01:30:26.900-03:00

This is Part I of a 3 part series detailing common problems with software estimates and some simple ways to handle them.Unfortunately, most of us software developers are pretty bad at estimation. Is it because we're incompetent? Of course not. It's because coding is creative work, and creative work is unpredictable. Writing software is not like working on an assembly line in a factory.

Ryan Cooperhttp://www.blogger.com/profile/08635857155555755249noreply@blogger.com8tag:blogger.com,1999:blog-34741702.post-31828408073995317902008-09-30T00:30:00.003-03:002008-09-30T00:42:56.473-03:00

This bit of news is a little late, but hopefully still useful to someone out there who's interested in introducing agile practices to their project. A few months ago, Addison-Wesley released a great resource for teams and coaches relatively new to agile methods: Agile Adoption Patterns by Amr Elssamadisy. Unlike much of the Agile literature, this book doesn't just tell you what the end of the

Ryan Cooperhttp://www.blogger.com/profile/08635857155555755249noreply@blogger.com1tag:blogger.com,1999:blog-34741702.post-32525006868396864342008-05-20T00:09:00.009-03:002008-05-20T01:09:13.663-03:00

I was going to write a whole post about lean documents, but while doing my research, I quickly came across this article by Scott Ambler over at AgileModeling.com. It's a long read, so if you're short on time, read the Critical Points and Why Do People Document? sections. The former makes a great print-out list for your cubicle wall. The latter is more politically sensitive, so I wouldn't post it

Ryan Cooperhttp://www.blogger.com/profile/08635857155555755249noreply@blogger.com0tag:blogger.com,1999:blog-34741702.post-23137069890556839692008-01-06T21:53:00.000-04:002008-03-09T18:26:52.699-03:00

A couple years ago, I was an avid Texas Hold 'Em player. For about a year, I played 4 tables at a time online for a few hours a day, I read poker books, and I made enough money to pay my rent. (Because you're playing against other players rather than against a casino, it's actually possible to make money at poker.) Eventually it started feeling like a grind instead of a hobby, and I gave up on

Ryan Cooperhttp://www.blogger.com/profile/08635857155555755249noreply@blogger.com21tag:blogger.com,1999:blog-34741702.post-89273224710468525452007-10-01T20:14:00.000-03:002007-10-12T10:29:19.106-03:00

Agile software development is about asking a question, taking a best guess at the answer, acting on that assumption, and then back to asking a question about what happened as a result. It's about gathering feedback and acting on it in a continuous cycle. That's it. Iterations and retrospectives are the core of any shift towards agility. They are axiomatic; everything else can be derived.All the

Ryan Cooperhttp://www.blogger.com/profile/08635857155555755249noreply@blogger.com10tag:blogger.com,1999:blog-34741702.post-49670588717470857162007-07-16T19:03:00.000-03:002007-07-23T09:22:47.077-03:00

I did my best to select books I believe have something to offer for both those already doing agile software development and those who are curious about agile but remain skeptical. I'd like to think that even if you think "Agile" is a useless buzzword, you'll find something useful in each of these books. Quite simply, they are books that have changed the way I think about software development and

Ryan Cooperhttp://www.blogger.com/profile/08635857155555755249noreply@blogger.com48tag:blogger.com,1999:blog-34741702.post-19687616895817360742007-06-24T22:55:00.000-03:002007-07-02T15:21:06.679-03:00

I just wrapped up a contract with a large corporate client. As is the case with almost all large organizations (even those attempting to transition to agile practices), there was no shortage of wasteful corporate policies and procedures.Nothing frustrates lean-thinking people quite the way inefficient or wasteful processes do. We all want our expertise and abilities to be leveraged to create and

Ryan Cooperhttp://www.blogger.com/profile/08635857155555755249noreply@blogger.com1tag:blogger.com,1999:blog-34741702.post-55271147439603840752007-06-11T08:38:00.000-03:002007-06-12T09:13:28.794-03:00

While tackling some long-overdue refactoring of a particularly tangled part of our current project, Dmitri and I were faced with the task of updating some long and unreadable unit tests that we had just caused to fail.We had made a classic mistake earlier in the project and neglected technical issues like dependency management in a rush to be productive and show our customer some quick progress.

Ryan Cooperhttp://www.blogger.com/profile/08635857155555755249noreply@blogger.com3tag:blogger.com,1999:blog-34741702.post-10327161229877387752007-04-04T22:55:00.000-03:002007-07-02T15:19:28.711-03:00

We've all been there. The deadline is looming, everything is behind schedule, and you're in a rush to finish the FooBar module. You're puzzling over one last glitch. You know how to fix it, but it looks like it will take a minor redesign of the module... probably 4-5 hours of work. You just don't have that kind of time.Suddenly a clever idea strikes you. Hmmm... it just might work. You realize

Ryan Cooperhttp://www.blogger.com/profile/08635857155555755249noreply@blogger.com20tag:blogger.com,1999:blog-34741702.post-806075043276356632007-03-05T21:56:00.000-04:002007-03-05T22:59:51.821-04:00

I was sitting in construction-induced gridlock a few days ago when I had an epiphany. In retrospect, I can't believe I made the same mistake that everyone else makes. I can't believe I considered traffic jams a bad thing. Traffic jams are awesome!On the surface, this isn't obvious. But once you begin applying best practices of software project management, it becomes clear that a traffic jam is a

Ryan Cooperhttp://www.blogger.com/profile/08635857155555755249noreply@blogger.com4tag:blogger.com,1999:blog-34741702.post-71804513913102117942007-02-19T15:11:00.000-04:002007-02-20T14:35:25.020-04:00

Many organizations try to adopt agile development by plugging in a set of engineering practices without changing the organization's management style. Fortunately, depending on your starting point, some big gains can be made by adopting more effective engineering practices like test-driven development and continuous integration. Unfortunately, to make any big leaps in productivity and

Ryan Cooperhttp://www.blogger.com/profile/08635857155555755249noreply@blogger.com6tag:blogger.com,1999:blog-34741702.post-68127166690145016772007-02-06T10:59:00.000-04:002007-07-02T15:23:20.717-03:00

If you think your job is to do what the customer* tells you to do and build what the customer tells you to build, you are at risk of creating this:We as software professionals have a responsibility to our customers that goes beyond giving them total control. We are responsible not just for writing code; we are responsible for helping to create a useful product.A few days ago, I was listeneding

Ryan Cooperhttp://www.blogger.com/profile/08635857155555755249noreply@blogger.com0tag:blogger.com,1999:blog-34741702.post-40283857376949991452007-01-05T11:38:00.000-04:002007-01-15T23:38:18.565-04:00

I finally got around to reading an excellent article by Alistair Cockburn entitled Are iterations hazardous to your project?. He states the case that often iterations devolve into mere planning windows, without resulting in valuable feedback from customers on running, tested features.Feedback is the key to agile software development. Agile techniques (from pair programming to TDD to tracking

Ryan Cooperhttp://www.blogger.com/profile/08635857155555755249noreply@blogger.com1tag:blogger.com,1999:blog-34741702.post-10460036655418083992006-12-21T15:28:00.001-04:002007-07-02T15:24:08.385-03:00

I recently completed Certified Scrum Master training with Mishkin Berteig. One of the many interesting tidbits that came up over the course of the weekend was Mishkin's preference for treating every bug as the team's #1 priority as soon as it is discovered. (This is similar to the stop-the-line mentality of lean development.) I found this interesting, because it goes against the Scrum practice of

Ryan Cooperhttp://www.blogger.com/profile/08635857155555755249noreply@blogger.com15tag:blogger.com,1999:blog-34741702.post-8333168546696509832006-11-15T23:58:00.000-04:002007-07-02T15:25:02.653-03:00

In many traditional organizations, developers end up making business decisions that they have no right making. Maybe they are not able to get timely feedback from a business expert. Maybe they are so 'sure' of the answer they just don't bother asking. Maybe they are so knee deep in technical details they don't realize they are making a business decision. If they make the wrong choice, this can

Ryan Cooperhttp://www.blogger.com/profile/08635857155555755249noreply@blogger.com1tag:blogger.com,1999:blog-34741702.post-1161146096931464762006-10-18T01:14:00.000-03:002007-07-02T15:26:22.132-03:00

I was watching the movie Goodfellas a few nights ago, and a scene towards the end got me thinking. In the scene, Ray Liotta's character Henry is on bail after being busted by federal agents. He's having lunch with Robert De Niro's character Jimmy. Henry is trying to figure out if Jimmy's going to have him killed, and Jimmy is wondering if Henry is going to turn him over to the feds. Meanwhile, by

Ryan Cooperhttp://www.blogger.com/profile/08635857155555755249noreply@blogger.com59tag:blogger.com,1999:blog-34741702.post-1159974960002505572006-10-04T11:56:00.000-03:002006-11-15T23:57:52.145-04:00

The blogosphere is abuzz about Steve Yegge's condemnation of what he calls 'Bad Agile' (that is, agile anywhere except Google). Everyone has been contributing their two cents worth, and there have been some interesting responses. The best one I've seen so far comes from Jeff Atwood over at Coding Horror:"The whole FogCreek/Google-Is-So-Totally-Awesome thing is an annoyance. But I have a deeper

Ryan Cooperhttp://www.blogger.com/profile/08635857155555755249noreply@blogger.com0tag:blogger.com,1999:blog-34741702.post-1159326547678538122006-09-26T22:43:00.000-03:002006-11-15T23:57:52.064-04:00

We have been using Scrum since I joined the team at the end of January. Over the course of the last 8 months, we have started using several XP practices. It took a long time, but we've finally gotten to the point of using a story card wall. Well, at this point it's actually a task card wall, but it's a start :). (For those not familiar with Extreme Programming, or XP, a story card wall is a big

Ryan Cooperhttp://www.blogger.com/profile/08635857155555755249noreply@blogger.com55tag:blogger.com,1999:blog-34741702.post-1158756405984449592006-09-20T09:46:00.000-03:002006-11-15T23:57:51.853-04:00

How's that for baby steps? ;)

Ryan Cooperhttp://www.blogger.com/profile/08635857155555755249noreply@blogger.com5