agile

, 3 comments ,

Yeah, Jon gets it

Last night I had the pleasure of hearing Jon Stahl‘s introductory presentation on “Agile Explained” at a joint meeting of Cleveland IEEE and the Firmware Engineers of Northeast Ohio. The lighting was not so good for picture-taking on the LeanDog boat, so sadly there are no photos to share.

It was a nice crowd, although I’ve got to say one of the least diverse I’ve ever seen even at a technical event. Being mostly hardware and firmware engineers, they were skeptical about the idea of continuous deployment to production for obvious reasons; the guy sitting across from me used to design circuits for pacemakers! But they asked excellent questions, and in true Agile style Jon gave them The Simplest Answers That Could Possibly Work.

More

, 3 comments , , , ,

On Releasing Early

Jason Cohen guest-posted in December 2009 on the great blog On Startups, disputing the startup cliche that it’s always good to release your product early. He makes a good case to the contrary, although like some commenters I don’t think the iPod is a fantastic counterexample. (I mean come on. It’s Apple. They can get away with wild new design ideas, it’s what they do.)

My attention was grabbed by one of the comments in particular, from Trevor Lohrbeer. He says, in part:

Selling the product before release can also have the advantage of financing the development while at the same time focusing on the customers who are willing to put their money where their mouth is. It gets rid of the biggest problem of eliciting feedback, getting feedback from people who will never buy your product anyway (or may never buy at a price you can make money at).

Which, it should not surprise you to know, reminds me of a story.

More

, , 3 comments , , , ,

80% of what?

I’m a big believer in the 80-20 Rule. If you haven’t heard of this, it’s the idea that almost everything you do yields 80% of the benefit with the first 20% of effort. Similarly, you’ll find that 80% of your sales come from a 20% subset of your offerings. Stuff like that.

Sure, it’s a back-of-envelope rule of thumb sort of deal, but still a useful planning concept. (I love heuristics.)

On Monday, I blogged to the effect that non-software startup companies be satisfied with commercial off-the-shelf software that satisfies 80% of the functionality they require… because that’s so much cheaper than embarking on a new project when you are already hard up for cash.

More

, 2 comments , ,

The way I do the things I do

Over the past few years, I’ve studied what it means to market and sell professional services like mine. Honestly, I’m in a weird place with that, because I’m a huge geek (and still speak FORTRAN fluently) but a lot of what I do is what is sometimes, probably condescendingly, called the “soft skills” realm.

That makes it hard to answer that inevitable question, “So, what do you do?”

I used to reply with variations that started, “I’m a software developer” or “I’m a Unix guy.” But that doesn’t quite tickle the people who really need me.

More

, 6 comments ,

"Just Ship It."

In my experience, most software-dependent startups fail because they never actually finish the software. It’s really that simple.

I’m trying to figure out how I feel about Jeff Atwood’s recent proclamation: “Version 1 Sucks, But Ship It Anyway.” As a connoisseur of Software Projects That Suck, I get Atwood’s point: you don’t really know what’s wrong with Version 1.0 until some real customers get to play with it and let you know what they think. I’ve often spent days or weeks perfecting a feature that nobody cared about! Why not save that time by getting feedback first?

More

, , 1 comment , , ,

The silver's all around you

This is a response to Peter Kretzman’s coherent and insightful blog post, “No silver bullets. Really!” You should go read that first. I’ll wait.

Peter’s post, in turn, is a response to the classic paper, “No Silver Bullet: Essence and Accidents of Software Engineering” by Fred Brooks, in which Brooks says that complexity in software development is essential, not accidental. You should read that too.

Now here’s what I think.

More

, 4 comments , , ,

Code Farming: Sprouting Some Methods

I am trying, with only partial success, to apply what I’ve learned in Working Effectively With Legacy Code by Michael C. Feathers.

Feathers is a huge advocate of test-driven development. He puts it out there on page xvi: “Code without tests is bad code.” He defines “legacy code” as, strictly speaking, any code that isn’t already under unit tests. At first it struck me as a funny definition, because obviously lots of code is written today–even by me–without unit tests, and how can it be right to refer to software nobody’s even thought of yet as “legacy”? But for purposes of the book it works.

More

, 1 comment ,

When you're stuck

It happens a lot, especially when working on legacy code, that you can’t figure out a “business logic” algorithm that isn’t already well documented. Sure, it’s in the code, but so are a million other things, and you can’t eyeball the part that does all the calculation. The client is asking for a change or a fix and you’re not sure where to start.
That’s when I think you can do three things at once: improve the overall structure, impose some unit testing, and solve the problem you were asked to. Refactoring does all of these.More

, 1 comment , , ,

The other essential Agile ingredient

I must not fear.
Fear is the mind-killer.
Fear is the little-death that brings total obliteration.

–the “litany against fear” from the science fiction novel Dune

Yesterday I got a call from a prospective client whose Project Does Not Yet Suck, but it’s starting to make little slurping noises.

The situation calls for someone who is “aggressive without being arrogant” and “can handle pressure” while “getting stuff done.” And I thought hey, maybe this project isn’t necessarily right for me for some other reasons… but she did catch the spirit of what I talked about a couple weeks ago.

See here. Humility is not contradicted by effectiveness. It just isn’t. They’re different things.More

, 12 comments , , ,

Programmer optimism, and the "Death March"

I’m tired of hearing lines like “programmers are such optimists,” said in a disparaging way, by people who should know better. It’s a common refrain in corporate offices, usually when a software project is running late. Often the blame is placed on the programmers who are working for free on nights and weekends to make stuff work.

The project isn’t late because developers are braggarts. It’s because management has assigned them too much to do, which, as Peter Kretzman warns is the best way to not get what you want from your I.T. organization.

The “optimist” accusation is a cheap shot, and here’s why.

More

Page 3 of 4
1 2 3 4
1 2 3 4