Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reality Driven Development: Fixing Project Management in Software

brightball.com

Post reply on HN
Print view View original

31–40 of 147 posts

Re: Reality Driven Development: Fixing Project Management in Software

#31

Post by brightball »

Benjammer wrote: post #22
perlgeek wrote: post #21

Earlier quoted context omitted.

Kanban plus occasional pair programming sounds like a great software development methodology, but it's not project management. It doesn't provide high-level estimates that management provides, doesn't do budget planning for you etc. How do you approach these topics with Kanban?

I came out of the article with the same question. I was almost jumping up from my desk with excitement through the first 3/4 of the article, but then the conclusion felt a bit lacking when it never directly addressed the estimation problem...

You don’t. You focus on efficiency and throughput.

Complexity and high variability of estimates is the real problem. You can address that some by training developers on how to estimate, which I’ve heard called calibration, and then spend a lot more time digging in up front on those estimates.

Long term, a ball park can give a good idea but most aren’t going to be more accurate until we dig in. If you are choosing between projects based on expected ROI then diving in ahead of schedule to get a clearer picture makes sense.

If you are delivering a specific product no matter what, then you optimize for throughput.

It’s more valuable to tune the engine so you can drive 70mph than to slow down to 20mph with the goal of accurately predicting your speed.

Re: Reality Driven Development: Fixing Project Management in Software

#33

Post by commandlinefan »

> knowledge of existing libraries, algorithms, systems, permissions

I can't help but notice, also, that no project management "methodology" emphasizes (or even allows for) time spent researching/learning existing libraries, algorithms, systems, permissions, even though I think everybody would agree that this is where you're going to get the biggest payoff.

Re: Reality Driven Development: Fixing Project Management in Software

#34

Post by overgard »

One of the things that drives me crazy about agile is the strawman that is "waterfall". There's this notion that if you're not doing kanban or scrum you're a dinosaur. I've worked at places that didn't have some sort of Methodology, and you know what? It was fine. Things still got estimated, work got done, we just didn't arbitrarily shove things into 2 week windows or have painfully elongated planning sessions because of "planning poker"

As far as I can tell "agile" mostly is about predictability, not about efficiency. Most of the places I've worked, when we switched to agile, the efficiency of the team got worse, but management was generally happy because they felt like they had much more control.

Re: Reality Driven Development: Fixing Project Management in Software

#35

Post by giulianob »

amarkov wrote: post #17
giulianob wrote: post #4

Earlier quoted context omitted.

I think what a lot of people fail to take into account is the amount of effort it can take to "estimate" tasks. From my experience, the more pressure there is to give an estimate the less time they want you to spend researching the work. To increase the accuracy of an estimate, you need to do more research and if you take that to its logical conclusion then the best estimate is given after the work is completed. So t…

High level estimates aren’t optional for most development. Customers waiting for an important feature won’t take “ it’ll come when it comes, estimates aren’t real” as an answer. You can skip low level estimates, but the consequence of that is that high level timelines are uninformed by them. That’s how you end up in the archetypal situation where all the engineers know a project will slip while their managers report…

My point is you need to balance the effort you're putting into your estimates vs getting work done. Customers also won't be happy when you give them a date and don't meet it. Honesty is important too.

Re: Reality Driven Development: Fixing Project Management in Software

#36

Post by Benjammer »

maxxxxx wrote: post #29
jarl-ragnar wrote: post #26

A few years ago I was technical lead for a team that worked one of the largest IT systems in the UK that you've probably never heard of. The customer was truely enlightened and would fund short technical de-risking studies to understand and scope challenging tasks before asking the contracting organisations to produce a firm price proposal for delivering the capability. This worked well and was driven by his understa…

For stuff that's new I always tell management to give us a certain amount of time (weeks or even months) to figure out the major unknowns. After that has been done they can get a reasonable estimate or cancel, whatever they want to do. This seems to be the only realistic way to go about things.

I think engineers need to start talking about this concept in a much more official way, and approach it with the business side as another full task type called "Technical Discovery," with clear goals and a clear time-box.

Re: Reality Driven Development: Fixing Project Management in Software

#37

Post by vvanders »

munificent wrote: post #15

The author touches on this indirectly a couple of times, but I think the main realization this gives me is that we tend to conflate two things when doing software project management: * Getting the project done well and on time. * Evaluating the performance of invidual programmers. This is probably a natural thing to do because one measure of "good programmer" is "gets projects done well and on time", but I think dire…

I think a great way to treat that is to look at the individual contribution and measure against how that person delivered on the micro of the project rather than the macro of the business success.

I've had a successful career(delivering what I consider good work) on some real stinker projects. Usually though it's only been when things are framed in the above way.

Re: Reality Driven Development: Fixing Project Management in Software

#38

Post by brightball »

Benjammer wrote: post #25
brightball wrote: post #9

Earlier quoted context omitted.

That pressure can be very real. Personally, I don't see a tremendous amount of value in overthinking estimates as much as re-evaluating estimates once the task starts. The methodology I mentioned calls for exactly that, estimating best case, realistic and worst case...and then re-evaluating once the work starts. You never really know until somebody dives into the work and it's rare to actually get time before an esti…

>Treat the estimate as a best guess and then re-evaluate when you have better information. Any suggestions for how to effectively communicate a "best guess" and a "re-evaluation" to a business side that basically demands "hard deadlines" for projects?

EDIT: My original answer is below but a much more concise and clear explanation is in one of the other articles that was linked in the comments.

https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...

Check out his "4) Pile of wood blocks"

My original answer though ->

Forward along this article?

The Software Estimation book mentioned in the article does a really good job of breaking it down.

Hard deadlines come with a lot of questions, like why? Is there a trade show? An investor meeting? A marketing campaign?

Is it really a hard deadline? Specifically, if the product isn't ready yet are you planning to launch no matter what because we have to?

If not, then it's not a hard deadline and deadline needs to be reframed around goals.

You'll never hear Apple announce a product until it's actually ready to ship.

Usually hard deadlines come from announcing something that doesn't exist yet. The outcomes are usually buggy, rushed systems or missed deadlines that make companies look bad.

If it's for a trade show, the question is closer to "what exactly do we need for this trade show?" because management will always say "everything!"

I always tell the story of a particularly bad client that I had years ago who insisted that he had to have a project completed 3 weeks ahead of when we told him it would be ready. My partner and I killed ourselves, gave up weekends, worked crazy hours to hit his deadline for him.

And we also monitored the parts of the application that he had us create. He didn't even look at them until 2 months later.

After that we learned to create "Rush Rates" when requests like that come in, because if demanding something be done faster has no cost to the person asking for they are going to continue to ask for it.

At a company with salaried employees, management has to understand that rushes and scope creep come with tech debt and quality issues in order to hit "the deadline". Understanding things like "tech debt is not just a task you do later, it actually makes everything you do worse" are critical in that regard.

When you can get a manager to say "I don't care of quality suffers as long as we can show it on the floor at the show" then you know it's a deadline. Ideally, point them to that book to help them understand the difference between estimates, commitments and targets.

Re: Reality Driven Development: Fixing Project Management in Software

#40

Post by retbull »

brightball wrote: post #31
Benjammer wrote: post #22

Earlier quoted context omitted.

I came out of the article with the same question. I was almost jumping up from my desk with excitement through the first 3/4 of the article, but then the conclusion felt a bit lacking when it never directly addressed the estimation problem...

You don’t. You focus on efficiency and throughput. Complexity and high variability of estimates is the real problem. You can address that some by training developers on how to estimate, which I’ve heard called calibration, and then spend a lot more time digging in up front on those estimates. Long term, a ball park can give a good idea but most aren’t going to be more accurate until we dig in. If you are choosing bet…

While I agree it is more valuable to optimize for speed for each person speeding there is a traffic cop worried more about what the sign says than the final result. Sure a company might want to go as fast as possible because it makes them lots of money but the accounting people now can't write budgets very easily so they push for more accurate estimates.
Post reply on HN