Hacker News new | comments | show | ask | jobs | submit login

In the trenches, methodologies don't get projects done. Dave Thomas's original description of agility seems an accurate description of how code actually gets made--and that description is deliberately not a description of a methodology. I ship working code every day, and my clients are happy, despite the fact that I'm not following any definable methodology. Coding is a messy process. Codebases evolve in many ways: They advance by leaps and bounds, they stagnate, they regress, they sputter along, they bloat--often all at the same time. Sometimes you write tests first, sometimes you code first. Sometimes you whiteboard first, sometimes you write up a detailed spec. How do you know what strategy to adopt at any given moment? You can try to formalize it all you want, but in reality, the choice is usually made on intuition.

That last point--the key role of intuition--is one of the biggest reasons you can't package up effective coding as a book, a manifesto, or a training session. Which implies something managers may find distressing: There is no silver bullet; a coding team's only salvation is smart coders.




What is it that keeps you shipping working code every day? That's not the state of nature, you've clearly made some kind of decision to do that.

80% of agile can be summed up as: limit work in progress, and (almost as a necessary consequence of this) ensure any given piece of work can go from initial requirement to deployed to customer very quickly. My "in the trenches" experience is that whether or not a company follows this is the most accurate single predictor of whether it succeeds. So methodologies do, in fact, get projects done.


> What is it that keeps you shipping working code every day? That's not the state of nature, you've clearly made some kind of decision to do that.

Good question. If you mean: "Why do you choose to ship code?" then I suppose it's my desire to please my clients and stay employed. If you mean: "How do you manage it?" then it's what I hinted at earlier: Good intuition, experience, a precise and logical mind, and thoughtful use of tools.

About tools: My tools are important to me, but I don't see them as a silver bullet. It's like if you asked a carpenter about a "hammer-centric methodology." She would laugh. She'd say yeah, she uses a hammer all the time, but her hammer use doesn't amount to a methodology or a philosophy. Hammer use just comes about naturally as a consequence of recognizing nails that must be driven in.

Similarly for software: I don't use to-do lists because they're "agile." I use them because I need to remember the 20 different requests my client made yesterday. Could I live without Asana, Basecamp, or what have you? Sure. I'd just write my tasks in a text file. What if I couldn't use a text file? Then I'd put sticky notes on my wall. I need tools (everyone does), but I don't deify them.

> 80% of agile can be summed up as: limit work in progress, and (almost as a necessary consequence of this) ensure any given piece of work can go from initial requirement to deployed to customer very quickly. My "in the trenches" experience is that whether or not a company follows this is the most accurate single predictor of whether it succeeds. So methodologies do, in fact, get projects done.

I agree with all of the above except for the statement that "methodologies do, in fact, get projects done." I think the reason we disagree is that we mean different things by "methodology." I take "methodology" to mean a formalized process, like a recipe, that you can follow mechanically. By that definition, agility is the explicit rejection of methodologies.

But then, I'm not the god of word definitions. I don't get to say my definition of "methodology" is right and yours is wrong. So perhaps it's fair to say that we're each right insofar as we're permitted our respective definitions of "methodology."


I thought you must be kidding about the "hammer-centric methodology": Do companies actually say they have a "tool-centric methodology"?

Then I remembered one I saw just the other day:

> We offer a highly configurable Agile and tools-based software development methodology

They also have an "execution-focused leadership team" and "offer a number of flexible outcome-oriented engagement models assuring the success of our projects"

The whole page is like that!

http://accionlabs.com/company/why-accion-labs/


Wow. I've always wondered: Is this kind of empty, buzzwordy writing effective? Does it sell?

So many companies write this way. I could believe they do so only because their staff never learned how to write good sales copy. Or is there some actual merit to it? Do they know something I don't--namely, that buzzwords sell?


I think it's a joke, just based on the obvious word reuse:

> We are an innovation focused services firm with 100% focus in the emerging technologies. This razor sharp focus has allowed us to differentiate from our competitors in many different ways:


Maybe. Though the page, taken in the context of the overall site, doesn't scream satire. I'd be disinclined to put a joke page on my consultancy's website, but if I did, I'd be sure to make the joke 110% clear. So my suspicion is that the word reuse is just the writer's habit, not evidence of a joke. (Many writers have such habits, especially amongst those of us who aren't writers by trade.)


I've actually had some personal interaction with this company, and I'm pretty sure that the writing style is not satire and not a joke. It's the way somebody actually writes.


Oooh, you can work on Web 2.0 AND 3.0. I'm not sure if Web 3.0 is backwards compatible, though.


"a coding team's only salvation is smart coders"

Smart coders who understand that they're part of a team.

I've seen at least as many problems caused by people not working with those around them (whether they be other developers, users, testers or whoever) as caused by rank stupidity.

That's not to say there needs to be a massively formalised way of working together, just the fact that other people are involved needs to be a central part of everyone's thinking.

EDIT: A central and constructive part of their thinking I should say - thinking "I need to steer clear of all these other bozos" I guess qualifies as a central part of someone's thinking but isn't what I was getting at.


So true! A bunch of smart, arrogant lone wolves won't be very effective at software development.


I absolutely agree that there is no silver bullet. But there are quite a few lead bullets that when aimed accurately can make a real difference.

None of them are prescriptive methodologies, though. They are all things like incrementalism, automation, and high quality code.


Agreed 100%. I like your metaphor of lead bullets. There's no silver bullet that will win a war, but you sure aren't going to win without putting the lead bullets in the right places.


To torture the armory metaphor further, there are also land mines that you would want to avoid to keep from getting limbs blown off.

In that metaphor, traditional waterfall is a land mine filled with plutonium shrapnel and anthrax spores.


Well, unless when it isn't.

Some times you have a clear and well understood problem, and failures are very expensive. You'd be crazy to work on such kinds of environments with anything but waterfall.


Correct. One can see that very well defined in the NASA/JPL software guidance documents. Definitely not agile, but works for their situation.


I believe that clear and well understood problems with expensive failures actually exist, but are rare enough that the lessons there aren't really instructive for the vast majority of professional software developers.

Some people have to do underwater welding, but the methodologies there aren't appropriate for building cabinets, even though they are both types of construction.


Incrementalism and automation may be "lead bullets", but "high quality code" is more the target you are shooting at.


I'd disagree here and replace that with "fufilling business needs" - the highest quality code is meaningless if it doesn't do what your customer wants in the way they want it done.

Good craftsmanship is usually correlated with a good end product, but craftsmanship for its own sake is a hobby, not a career.


Indeed. The best code is no code.


Very likely, you have agility without even striving for it. I've met some teams that didn't adhere to "Agile" but were still working in an agile way. It's very possible to have agility without labeling yourself. Kudos to you.


Thanks! Yes, I'd say "agile" is an accurate adjective for how I work. It's the work style towards which I gravitate, absent any external pressure. Agility with a lowercase "A" that is, because I don't claim to meet any official definition of Agility.


You obviously have a process. It's just that you haven't formalized it yet and/or that it's too convoluted to be easily expressed in a marketable form for most human beings.


"...a coding team's only salvation is smart coders."

Yes!


How big is your team?


One team varies from three to six people. Another has maybe 20.

The larger team definitely produces more intermediate artifacts than the smaller team. You could say there's more process in that team. But it's still not formalized as a methodology. The larger team mostly just muddles along. I'd actually prefer to organize the larger team's tools a little better, e.g. maintaining a single, sane VCS. Even if we did that, I wouldn't claim we're following a methodology. (By my definition, artifacts and tools do not a methodology make.)


Teams beyond a certain size seem to require some intermediate artifacts. (Bill Joy described an ideal-sized team to be the number of people who can sit comfortably around a dinner table: so 3-6 is fairly perfect for his definition.) It seems like small teams can just keep each other in sync with quick conversations. They seem to be able to keep the design and requirements in mind at all times. Maybe it's the scope of what they're trying to solve or maybe it's some residual overhead that larger teams create due to additional communication "friction". I'm not sure. It's interesting though.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: