Hacker News Reader

Comment by efitz | Hacker News Reader

I am a security engineer but have been a business leader from time to time. Business leaders often need to plan around dates- eg ”should we spend $50k announcing at conference Y in month Z, or should we wait until month A?” “Our competition just launched; will we be able to launch this quarter (the board wants to know, and we have to report material financial impact items quarterly or face SEC fines)?”

Every team I have ever worked with hates planning; every team hates their methodology and thinks it’s stupid and inaccurate and why are those pinhead business people insisting on a date; it’ll be done when it’s done.

One of the primary jobs of managers at all levels is to plan and then execute in accordance with the plan. Some managers are good at it, many aren’t- the world is populated with people nearer the center than the ends of the bell curve.

So show me a methodology that mere mortals can implement successfully. If all you can do is complain and point out unicorn 500x engineers (yeah try hiring for that characteristic, good luck), then I don’t want to hear it. But if you have a practical idea on how to “solve” planning, then you have my full attention.

View on HN

> So show me a methodology that mere mortals can implement successfully. If all you can do is complain and point out unicorn 500x engineers (yeah try hiring for that characteristic, good luck), then I don’t want to hear it. But if you have a practical idea on how to “solve” planning, then you have my full attention.

TFA doesn't suggest hiring 500x engineers, it suggests taking steps to retain highly effective engineers (and highly effective teams) by not ignoring the evidence that they are not fungible.

A point the article also alludes to: often people are only “unicorns” due to the specific context they’re working on. Move them to a different project, and your high value person may be a net negative. And it’s not possible for people who aren’t familiar with a person’s work to anticipate how making that person switch projects will affect the quality or quantity of their output.

I just went through this, like... today.

"Tell me what date task X will occur on." -- where task 'X' takes 5 minutes, but has a long list of pre-requisites that take 1-4 weeks each, sequentially, of which 100% our out of our control.

...

That's not planning, that's fortune-telling. You may as well ask an Ouija board.

Planning is making sure the the pre-requisites happen before you attempt to start the things that depend on them. It is making sure that everyone is unblocked. It is making sure that nobody is wasting time going down a dead end. It is making sure that everyone is rowing in the same direction.

What I see from PMs is that they just want facts from the future, instead of solving problems in the here and now.

Until today, weeks into the project, I could not access the system that I needed. This was the key pre-requisite for 4x FTEs progressing on their own tasks.

The only thing the PM did is repeatedly ask me if he needed to move the date for the completion ETA.

I solved the problem. He did nothing to expedite progress.

Does it really matter which specific date this occurred on? No. It just had to happen as soon as possible. The trick is to make it possible, not to try to pin down exactly when "soon" will occur by repeatedly asking the same question in every daily stand up.

Why do we pay these people, again? Remind me?

That was the glory of the good ole Gannt Chart in what I might call Microsoft Project Based Project Management.

If you set your dependencies right, the dates would just slip by themselves, and it was easy to tell the bosses what slipped. Required a lot of printing and taping every week, and caused a ton of headache whenever people lied about their progress, and didn’t really work without a FTE project manager, but I have yet to see a supposedly better system actually work better on big projects.

Like the parent poster said, people are on a bell curve. It sounds like you may only have been exposed to mediocre, passable, or plain bad PM's so far in your career.

So I'll remind you: the reason we pay PM's is because good PM's can, and do, exist. I've only worked with a few great PM's, but they outshone their competition with just as much brilliance as the 10x among us engineers outshine the 1x. It's ironic that you would reduce PM's to a single heterogeneous caricature in reply to an article that is essentially saying that it's harmful to do so.

Woops -- *homogeneous!

>One of the primary jobs of managers at all levels is to plan and then execute in accordance with the plan

"Plans" can never be set in stone. They evolve based on the people involved and circumstances. A Manager's job is to understand his people and then Plan accordingly; not the other way around.

>If all you can do is complain

This is exactly the wrong way to frame the discussion. Pointing out that you are clueless is not complaining but raising issues which if unaddressed, will most probably result in failure of what is attempted.

> "Plans" can never be set in stone

Setting plans in stone was the entire Waterfall Methodology where contracts had requirements and milestones locked in and any deviation meant heavy penalties.

The first formal detailed diagram of the process later known as the "waterfall model" is often cited as a 1970 article by Winston W. Royce. However he also felt it had major flaws stemming from the fact that testing only happened at the end of the process, which he described as being "risky and invites failure". The rest of his paper introduced five steps which he felt were necessary to "eliminate most of the development risks" associated with the unaltered waterfall approach.

Royce's five additional steps (which included writing complete documentation at various stages of development) never took mainstream hold, but his diagram of what he considered a flawed process became the starting point when describing a "waterfall" approach.

https://en.wikipedia.org/wiki/Waterfall_model#History

Not when I have done waterfall - each waterfall phase can iterate

Show me a Software Engineering book that calls Waterfall that can iterate "Waterfall" rather than "Spiral" or "Iterative".

There is a big difference between the stages involved in "Waterfall Model" and the various techniques of combining, using and transitioning from one stage to another.

"Waterfall" specifies the What while "Spiral and Iterative" specify the How.

Absolutely Categorically Wrong!

This has been so endlessly repeated without thought that people assume it is a fact when the Truth is far from it.

Excerpts from wikipedia - https://en.wikipedia.org/wiki/Waterfall_model ;

* In 1983 the paper was republished with a foreword by Benington explaining that the phases were on purpose organised according to the specialisation of tasks, and pointing out that the process was not in fact performed in a strict top-down fashion, but depended on a prototype.

* Royce's five additional steps (which included writing complete documentation at various stages of development) never took mainstream hold, but his diagram of what he considered a flawed process became the starting point when describing a "waterfall" approach.

* In 1985, the United States Department of Defense captured this approach in DOD-STD-2167A[citation needed], their standards for working with software development contractors, which stated that "the contractor shall implement a software development cycle that includes the following six phases: Software Requirement Analysis, Preliminary Design, Detailed Design, Coding and Unit Testing, Integration, and Testing.

The "Waterfall" is what is imagined as a "Ideal and Rational" process (see D.L.Parnas' paper A Rational Design Process: How and Why to Fake it for motivation - https://ieeexplore.ieee.org/document/6312940). The stages in the model and the issues to be considered in each stage are what is important NOT their order. In practice it was always a iterative spiral model described by Barry Boehm - https://en.wikipedia.org/wiki/Spiral_model

Maybe you've never done big government contracts.

Totally irrelevant and no Ad Hominem please.

FYI, D.L.Parnas and Barry Boehm defined the field of Software Engineering. Almost all Govt./DoD standards are based on their research and writings.

TIL: "Winston W. Royce's final model, his intended improvement upon his initial "waterfall model", illustrated that feedback could (should, and often would) lead from code testing to design (as testing of code uncovered flaws in the design) and from design back to requirements specification (as design problems may necessitate the removal of conflicting or otherwise unsatisfiable / undesignable requirements)"

https://en.wikipedia.org/wiki/Waterfall_model#Modified_water...

Interesting because that's definitely not what's taught in the handful of Software Engineering books I've read, and steps backward are not canon (rather, they're called something besides Waterfall i.e Spiral or Iterative).

Looking at that page again, it looks like what I describe is called "pure waterfall".

This is a good article on the topic http://www.bawiki.com/wiki/Waterfall.html

That is indeed a Great Writeup!

Instead of getting lost in the comments, You should post it to HN and invite discussions with a title like "Most of what you have heard about the Waterfall Development Model is Wrong!" or "How the Agile folks have misled you about the Waterfall Development Model" :-)

Most books on Software Engineering are mere compendiums with nothing much to recommend them eg. the texts by Sommerville or Pressman. Two exceptions that i know of are those by Ghezzi,Jazayeri,Mandrioli and Pankaj Jalote.

This mentality of thinking is exactly the problem, I think. You want a tool that can solve an entire class of problems. We are telling you that no such tool can exist to do what you want, the problem and the tools don't work that way. Each project should be planned as a snowflake. Each project is different. Each team is unique. Every individual performs differently, even one day to the next. Stop looking for this tool to make these plans. It can't exist.

Do the hard thing and plan projects individually.

>This mentality of thinking is exactly the problem

Damn right!

>We are telling you that no such tool can exist to do what you want

This is exactly right and is the biggest problem with "Management" types. They want a "cookie cutter methodology" to solve all their problems so they can be spared thinking through each one. Hence the various "Management" fads and buzzwords.

The core of the solution lies with the Individual; understand their needs, wants, motivations, practice "Empathetic Management" and you will be successful.

Leaders may need to know some specific dates for some specific purposes. Responding to that need by demanding your methodology deliver a schedule for everything in case you need it is lazy and wasteful.

If your engineers are part of the same team, working on the same business goals, they'll be glad to contribute what you need to the decision about whether to announce at conference Y, and may even be able to suggest relevant aspects you haven't thought of.

> So show me a methodology that mere mortals can implement successfully.

Commit to a deliverable or a deadline, but never both.

“Ok awesome! Glad to hear you’ve committed to deliver widget, when do you think it will be done? We have four business units that were going to use wedgie but that’s getting decommed next year and they’d much rather avoid a pivot.

Oh and change restrictions start in six weeks, don’t forget that. BTW what’s your team’s vacation schedule looking like? We only get to roll over 7 days this year, hopefully they took some this summer haha!

Ok so anyway really would like some estimate that i can take back to product, you thinking January? Maybe get something up in test that they can kick around in what, a month?”

Etc etc.

"No."

It's remarkably powerful.

I would say an approach closer to the Heisenberg uncertainty principle would make more sense. The more information specified that can't be changed about the expected product the less information is available about the deadline, ans vice versa. Thus, the desired balance could be used depending on the situation, goals, budget, etc.

That was briliant and is already added to my quotes list.

Should I attribute it to xvilka or did you get it from somewhere else?

I think, it's my own idea but you never can be 100% sure, some kind of uncertainty always persist.

I'm not all to familiar with this kind of thing so I could be missing something, but what is a deadline without a deliverable? Surely "We will do something (literally "something", not a stand-in for X) and it will take a month" is worth nothing?

I worked for several years on an extremely large and popular sports news/results website, meaning all our deadlines were absolutely set in stone by the outside world – sporting events start on specific dates. The Tour de France sure as hell ain't gonna postpone a few days until we've finished our team profile pages.

So we committed to a deadline, but not a single deliverable. Scope would shrink and grow as delivery of each component progressed. Well in advance, for each major sporting event in each country where we operated, we would scope out literally every single thing we'd like to deliver, and then start work on the components in priority order. In each planning session as the event approaches we'd appraise whether we still have time to realistically deliver the next priority thing, and if not we'd skip it and move to the next - those that got missed out could wait until the following year (when the major features already delivered would need to evolve, not be implemented from scratch).

I learnt a lot from working on sports. Having third party deadlines that no-one could bitch about made us an extremely effective team at planning, estimating, and ruthless scope reduction.

You can have a fixed scope with a flexible timeline, or a flexible scope with a fixed timeline. If you try to have both, you'll incur an additional cost, which most companies avoid. It's a well known law of project management and software development.

Stop using methodologies actively preventing any kind of planning (mostly agile stuff). Return to waterfall, write lots of documentations, spend time planning architecture, resist urges to rewrite non-ideal solutions. Do not allow changes.

It'll take more time and result will not be as clean.

Basically learn from older engineering disciplines.

The two replies below yours at the moment capture what you're trying to say...

> This mentality of thinking is exactly the problem, I think. You want a tool that can solve an entire class of problems. We are telling you that no such tool can exist to do what you want, the problem and the tools don't work that way. Each project should be planned as a snowflake.

> This is exactly right and is the biggest problem with "Management" types. They want a "cookie cutter methodology" to solve all their problems so they can be spared thinking through each one. Hence the various "Management" fads and buzzwords.

Which is another way to say... if there was a system to do their thing, they wouldn't have to pay smarter people a lot of money to do it. Reliance on a system (any system) tells you that the people don't value your expertise, but rather see you as a cost to be minimized.

Also, build several prototypes of every important part of the product in order to learn how long they will take to be made and how each variant will perform, so when you make estimations they are as effective as possible; and then, make integration tests on the selected variants so you can reduce estimation risks due to integration. Just as in every other engineering discipline.

I can't really speak about managment here, but when I organize projects the three most important things are:

1. Create the room for every member of the team to comfortably do their job (what this means depends on the persons needs and at the work environment, communication structure, tools you provide them). Room not only means physical room, but also time, frame of mind etc. If everybody has 10 other daily things on their list they won't have the (mental) room to work on the project.

2. Communicate clearly why you think this is a workable plan and ask for feedback whether this is realistic. Communicate what happens if you are faster, what happens if you are slower. They are helping you, you are helping them, ideally both sides take away something from the project beyond purely finishing it.

3. Adapt, Improvise, Overcome. The primary goal should always be to finish the project in a good way, especially if the deadline is not a hard deadline, but one arbitrarily set by someone else. Defend the team, create the room for them. Don't let them slack around too much. A bit of slacking around is not too much, but precisely the right amount – this is the space needed if something goes terribly wrong.

A technique I read once (and lost the link) was to track both the estimated time metrics and the error in estimation for every engineer. Over time you could build reasonable error bars around every engineer's estimations, and then sum the estimates _with the confidence intervals_ together and figure out the probability of achieving a certain ship date.

That's what Fog Creek Software's FogBugz tried to do. I liked it a lot, it also allowed for some team structure planning (e.g. giving you a chance to see if your team consists of pessimistic estimaters or positive ones, and mix accordingly). Unfortunately, their marketshare got gobbled up by Jira.

I feel like pessimistic estimators are way more accurate and probably more intelligent than optimistic ones. I'd probably use software like that to fire half the team.

(edit: of course then I'd have to fire half the team again... and again... until only one or two incredibly depressed pessimists remained... tough call)

Why would you fire the team? The software shows you how their estimates relates to real world timelines, just adjust their estimate accordingly and the problem is fixed.

I never understood why managers get so upset over consistent time under estimates, just track it and add the relevant factor without telling the team and it should on average be on point.

I was sort of just reducing the idea to absurdity. I only work in small teams - everything I do is by feel. It's easy to tell if things are behind or not. Easy to tell if someone is wasting time, or if they're stuck on a problem, and extrapolate a new ETA. Honestly, the idea of trying to feed that into software seems heartless and inevitably wrong, but if I were going to do it, I'd opt for the pessimistic analysis.

> A technique I read once (and lost the link) was to track both the estimated time metrics and the error in estimation for every engineer.

To do this you need to communicate very clearly why are you doing it, and if it will have any influence on performance reviews. But I do think that monitoring estimates in this way will affect the quality of estimates.

A manager in my previous company noted everyone's estimations during sprint planning in an Excel sheet. No-one knew why, so I found myself thinking more about that Excel sheet than about making an well-founded estimation.

> But if you have a practical idea on how to “solve” planning

Seems pretty straightforward to me - just don't use dates in your plans. That means don't announce features which aren't complete. Don't plan marketing campaigns for unlaunched products. Embrace "Now, "Next" and "Later" as headings on your roadmap. There are many successful companies that operate like this, Nintendo being a famous example. It doesn't seem to hurt their bottom line - quite the contrary.

The usual issue that folks have with planning is that business leaders are simply not willing to spend the resources to do it accurately enough to answer the questions they're asking. Think how much time it would take to break 6 months of work for several teams into detailed stories and estimate each one.

It therefore seems they're basically wasting everyone's time, since dartboards and magic-8-balls are just as good as engineering estimates without details.

> So show me a methodology that mere mortals can implement successfully.

There's an impedance between "Bob can do task of type A really quickly" and "we need to make sure that people other than Bob can do the task or else we have bus factor = 1 and this poses systemic risk". Clearly these goals are not really in conflict. In general, assign the work to Bob, but understand the effect on timeline in case Bob is unavailable. How long would it take if Bob isn't available? Is it worth the inefficiency from cross-training Mike? Is Mike even interested?

Modern militaries are not majority staffed by combat soldiers. Less than 10%. The rest are support of one kind or another. Smart engineering leadership in large companies, if they care about shipping on-time, eventually realize that roles like PMs are less effective if they understand themselves to be bosses and more effective if they understand themselves to be support staff.

> One of the primary jobs of managers at all levels is to plan and then execute in accordance with the plan.

Yep, just as I thought. This is why those teams hated plans - because once there is plan they will be beaten and abused to make it, despite the plan being unrealistic from the start.

> Every team I have ever worked with hates planning; every team hates their methodology and thinks it’s stupid and inaccurate and why are those pinhead business people insisting on a date; it’ll be done when it’s done.

In that case, teams in which you worked had stupid methodology about planning. It sounds like your plans did not accounted for uncertainty at all. They did not accounted for what if we are not making it, which features will be cut.

> Some managers are good at it, many aren’t- the world is populated with people nearer the center than the ends of the bell curve.

And many of them are abusive or exploitative about it and there is nothing in business organization to prevent or at least acknowledge that.

I'm really confused what this comment has to do with the article (not about planning) and why it's the top comment on HN.

A lot of my planning is making sure the most effective engineers are working on the most important things.

It is about making sure resources are most efficiently allocated to meet the business objectives.

I'd imagine the corollary to this is assigning each of them the task you think they're most suited to. I think that's what used to be called "management".

I'm speaking as someone who has handled a fair share of timelines (with reasonable success) you have pointed out.

To begin with, it is interesting to see you lumping up different kinds of timelines. For example, the cost of not meeting SEC timeline different one compared to demo to be shown in a press conference.

> should we spend $50k announcing at conference Y in month Z, or should we wait until month A?

What is it that you want to announce? Product launch perhaps? Then let's work with the product folks to design it and then take it to engineers to figure out work estimate. Give them time to estimate; if the timelines don't match then reduce the scope.

> Our competition just launched; will we be able to launch this quarter

Sure, they launched this quarter. Do you know how long have they been working on it? If not then it's a similar exercise as above.

> we have to report material financial impact items quarterly or face SEC fines

Why are you telling me this? SEC doesn't ask for such reports overnight. You messed up by not telling us so fine it is. OR there is some human at the SEC with whom you negotiate.

> So show me a methodology that mere mortals can implement successfully.

If there were such a methodology we wouldn't be having this discussion to begin with. It would have been commoditised, similar to a car manufacturing assembly line.

What business people don't understand (or internalise) is software is a truly a new beast. It is a tool that can be applied in just about every domain. No such tool has existed ever in human history. If you want to disrupt a domain then you either develop expertise in it or hire them from the industry.

> If all you can do is complain and point out unicorn 500x engineers (yeah try hiring for that characteristic, good luck), then I don’t want to hear it.

In some cases that is indeed the reality. If you don't even want to acknowledge the reality then good luck hiring good people. If you say point out how Apple launches products like clockwork then I'll point out how they have had close to 50 years worth of experience and all the associated optimisations they have done with their supply chain and what not.

Reality is, whether you acknowledge or not, is full of detail[1]. It can't be bent to your convenience, unfortunately.

[1] http://johnsalvatier.org/blog/2017/reality-has-a-surprising-...

> What business people don't understand (or internalise) is software is a truly a new beast. It is a tool that can be applied in just about every domain. No such tool has existed ever in human history.

That's not quite true: the inventions of mathematics, writing and especially affordable material to write on were probably even larger culture shifts, but software and computers are of the same magnitude - perhaps it's easier to realize the shift needed in corporate culture when you compare it to those earlier changes.

You can just give a random guess on the timelines and save the developers time.

Reply on news.ycombinator.com