1. 8
  1.  

  2. 18

    I like the spirit here, but I can’t honestly get behind it very much.

    In the software industry, like in every industry, a business owner does not sell time.

    Unless you’re going to get into a very weird philosophical argument, there are actually many industries that sell time, in the form of access to equipment and manpower. Security guards would be an example of the latter, and the time I pay for in my shop space would be an example of the former. And the thing is that’s not a semantic distinction, but matters for his argument. For example:

    Estimates are to be avoided at all cost. They create needless pressure, competition, and participate in a toxic witch-hunt of who is the less productive.

    That is not reasonable. In the real world, I may need $THING, and I need $THING by $DATE. In that case, estimates are insanely important, even if for no other reason than making sane triage decisions. No, you cannot be as accurate as an ever-repeating manufacturing pipeline on a Kanban board, but you can meaningfully realize four weeks out that you have at least six weeks of work left, and make reasonable cuts to the deliverable (if possible) or changes to the contract (if not) to handle that.

    Further, while I don’t frame it as selling time to a client, if I don’t know that Sue is going to be done in two weeks, then I can’t sell services to another client with the assumption she’ll be available on the third week. So in that case, I am very much selling time.

    This problem continues when he gets into estimates:

    In the software development world, it is impossible to produce meaningful estimates, let alone precise ones, for anything but nano-tasks.

    This is not true. I do agree you cannot estimate tasks you have not done before, but any agency shop I’ve seen honestly does have a really good idea how long it’ll take to get a given piece of work done. They have their base CMS/shop/whatever platform, they know how long it takes to customize, and they can give you pretty sane estimates that they tend to hit. And if you can’t estimate when it’ll be done because it’s new, and you do need to have an estimate (e.g., for the reasons listed above), then you can and should do enough research in the open-ended phase so that you can estimate the remainder work.

    Frequent, time-based interactions between executives and engineers are one of the best way to crash a company. Having a meeting once in a week/month or other indicator based solely on time is meaningless.

    This is also incorrect. I have switched between management and programming multiple times. You know why managers want to have these weekly meetings? Because when I don’t do that, you won’t tell me you’re behind schedule. It’s not malicious; you’re not trying to deceive me. You’re just deep into deceiving yourself. Having regular time-based meetings helps prevent that.

    My favorite example of that is the quote, “we’re a bit behind, but we’re catching up,” told to me multiple weeks in a row. You probably genuinely believe that (in my experience, you always do), and so you won’t reach out preemptively. If I email you, you’ll also likely sit on the email, because if you respond to it in four hours (the thinking goes), you’ll be able to tell me you’re on time, instead of behind. The time-based in-person/Hangout-based meeting lets me get that data anyway, and I can realize, from your repetition a couple weeks in a row, that we have a problem.

    But even if you are on track, and you know you’re on track, programmers who are in flow are really bad at keeping the master schedule chart in their head. I emphatically include myself in this. And that’s great, because I’d much rather you/I spend brain RAM on coding. But as a manager, that chart is basically all I think about. So you being on schedule to wrap up the APIs is great, but if the documentation isn’t shipped on time to testing and integration so that their components will be ready in time, then it won’t count. So me talking or emailing you on a fixed schedule makes a ton of sense from the long-range master plan this author is so concerned about.

    I could go on about the rest of his points, but they basically just scream to me as a programmer who wants to code for the sake of coding, isolated from any business needs.

    1. 9

      I could go on about the rest of his points, but they basically just scream to me as a programmer who wants to code for the sake of coding, isolated from any business needs.

      That’s exactly the vibe I got as well. It’s all nice from a theoretical perspective, but in the real world there’s always time and $$ involved, and the author has no real world management/business creds to back up his ideas (as far as I can tell).

      Besides, it’s not like it’s impossible to put out a good product on a deadline. I’d agree that quality can sometimes be lost in a compressed schedule, but given enough time and planning, quality products are made all the time.

      1. 2

        you cannot estimate tasks you have not done before

        Most of the interesting work are things that have not been done before.

        1. 7

          Corollary: most work is not interesting.

          1. 1

            Fair enough. But can it be automated then?

        2. 1

          I think the core idea is the core idea behind the #NoEstimates movement.

          ie. If you are working full speed on the top business value item at all times, estimating will inevitably decrease your velocity and decrease the business value you are generating.

          However the downside to that is people keep selling what they don’t have… in which case estimation becomes critical to budgeting.

          Arguably most of the sorrows of the software industry is our addiction to buying and selling vapourware.

          1. 8

            Is that really a thing? Because it’s easy to imagine counter examples. Feature X will deliver value 11 after 10 weeks work, feature Y will deliver value 1 after one week. Feature X is clearly higher value, but if you ship Y first you can be making money the whole time you’re making X. You can’t make this analysis without time estimates.

            1. 3

              We need to note a couple of things about the industry….

              You don’t “hire and fire” as it is A Very Bad Idea. The overhead of getting up to speed with product / code / tools / processes / domain can easily be months.

              And the effect on morale on the rest of the team is terrible.

              Thus we can assume your devs will be employed for at least a year.

              ie. Usually some time much much greater than the time to deliver a feature.

              if you ship Y first you can be making money the whole time you’re making X.

              If your choices are dominated by cash flow considerations yes. You need to estimate well enough to fit into your cash flow.

              If you’re not dminated by cashflow, you assume that feature will be churning out customer value forever. ie. Your calculation gets swamped in the long view.

              On the other hand if you are a startup founder that has been forced to take a truth serum…

              How well will the team talk go where he says, “Due to tight cashflow, your ability to pay your mortgage and feed your kids depends on your ability to estimate with no more than 10% error.”

              It’s why experienced devs are either in the founders seat or leaving the risky startup jobs to the young and excessively optimistic.

              Conversely the error in your estimates of cashflow will massively exceed even the crappiest estimates of ye average dev!

              Why squeeze precision out of the dev when it’s swamped by the error is on the other side of the equation?

              It’s also why startups seem to rely grovelling ability and the sunk value fallacy to squeeze more out of VC’s.

            2. 2

              I think the core idea is the core idea behind the #NoEstimates movement.

              Though, for me, the #NoEstimates movement is more about not estimating every task (which is already sliced arbitrarily). It isn’t opposed to “we need a clean version of the product on Feb 24th for presentation, is that feasible”?

              The problem of tiny estimates is that they are summed up, so the errors sum up. And the error is always biased towards taking longer.

          2. 3

            I’m in total agreement with the need for longflow, but…

            There is a danger of throwing the baby out with the bath water here….

            …there were some very good reasons behind agile, especially the extreme programming form of it.

            Alas, scrum came along and poisoned the well, but in reaction to that we should take care to address what extreme programming was attempting to address.

            • You are making software for a human. What you do will change the way that human behaves in ways he can guess at, but will only know when he uses the software. (Conversely if it doesn’t change the way a human behaves…. why the hell are you bothering to write the software?) Thus good communication and iterative incremental delivery is A Good Thing. That said, the iterations should be long enough to make customer impacting differences, and communication should be throttled to prevent loss of flow.

            • The kanban principle “Minimize work in flight” enables flow and prevents rapid context switching between tasks.

            • Estimation is toxic, but where the order of work isn’t driven by technical consierations, delivering highest business value soonest is vital.

            • CEO’s come and go like mayflies compared to the life time of software. However, the lifetime of the software is bounded above by whether anybody cares to fund development of it.

            • The ability to meet changing goals has high business value, so design your software and processes to emphasize flexibility.

            • Stability / code freezing is one strategy to manage risk. Unfortunately it is a very bad and very costly strategy. Use/emphasize other strategies.

            • The need for estimates are driven by the business model of estimating and selling future work, rather than selling work done. Never sell future work, only work done.

            • Remember price has nothing to do with cost, price relates to value to customer and price of alternatives. It has nothing to do with how much it cost you to do the work.

            • The only relation between price and cost is if your expenditure exceeds your income you starve and your software dies.

            1. 2

              Remember price has nothing to do with cost, price relates to value to customer and price of alternatives.

              And this is where a lot of selling future work and estimates come from.

              One of the customers alternatives is to ask someone else to estimate how much it would cost to implement (something better) than what you are selling.

              1. 1

                Even if you only sell work already done (e.g. by releasing a new product), you still need estimates for how long this work is going to take. Otherwise you’re signing up for an indefinitely long period of extra costs for something that’s only going to start producing unknown revenues at an unknown point in the future. That clearly doesn’t make sense.

                1. 2

                  Conversely your options are….

                  1) Carry on working on the highest business value item.

                  or

                  2) Go home and play tiddly winks.

                  No amount of estimating is going to change those options, except to impose additional overhead.

                  The only useful thing estimating may do for you is to tell you go home sooner.

                  However, I would argue if you are sailing that close to the wind, you should be looking for fatter margins.

                  You would be better off devoting your time to finding a more lucrative market, than estimating ever more finely whether the most useful thing you could do to your current product could possibly turn a profit.

                  If you find a more lucrative market, you’re in state 1. If you can’t find a more lucrative market and are sailing really close to the wind…

                  It’s time to go home.

                  The most insightful thing I have read in ages is… https://hackernoon.com/12-signs-youre-working-in-a-feature-factory-44a5b938d6a2#.j74n4imoi

                  There is a tremendous emphasis on estimation and prioritization…. and zero emphasis on validation.

                  Did we deliver the right thing? Did anybody care? Are people actually buying more / paying more? Has customer satisfaction gone up? By how much?

                  We said this thing was more important than that thing.

                  We now have delivered this and that.

                  Were we right about this being worth more than that? If not, why not?

                  Do the prioritization step, then delivery, then the validation step first, then if you have time and strength consider estimation.

                  1. 1

                    Or to put it another way….

                    You can choose to go home and play tiddly winks because you estimate the next feature will take too long, or because the nobody gave a shit about the last feature you delivered or about anything else on your todo list.

                    Estimation is wildly error prone and doesn’t tell you whether anybody gave a shit or not. You could estimate perfectly…. and go bankrupt.

                    Which is the more valuable info to be chasing? How long it will take? Or whether anybody really wants it compared to what else you could be doing?

                    1. 1

                      I’m commenting from the position of a small business owner (which is what I’m familiar with), whereas you are perhaps looking at things from the point of view of a large company with a lot of resources. Or perhaps you were talking about incremental additions to an existing product? I was thinking about adding a new product to a company’s existing product(s), which requires a different decision process.

                      I agree with you about prioritisation and validation (and I liked the feature factory post FWIW) but I think you are trivialising the decision making involved in adding a successful new product, particularly in the context of a small business.

                      Prioritisation and validation are necessary, but by far not sufficient. If I’m going to embark on creating a new product, I absolutely want to know how long it will take me to create something that I could start showing to potential customers to validate it further. Is it a month? A year? What’s going to happen to my costs and revenue in the meantime? If I can’t support the costs of development for a year, then it’s a non-starter and I need to be looking for other opportunities. Making such decisions requires estimates.

                      1. 1

                        As I said here… https://lobste.rs/c/tp42jk Cashflow can be a major bummer.

                        It can dominate your decisions.

                        That said, the errors in your estimation of cashflow (usually) completely dominate the errors in the devs estimates of development time. (And that really is saying something!)

                        Conversely, clearly you have spare dev capacity to develop a new product. What are you going to do? Hire and Fire to fit the cashflow?

                        It often takes 6 months to get a dev fully up to speed. Very very inefficient approach.

                        So you’re sort stuck in a suck it and see situation.

                        Fire them and secure your cashflow but lose institutional knowledge?

                        Or choose the most lucrative target and go for it.

                        What else are you going to do? Let the devs kick their heels until you find one that fits the budget / cashflow?

                        Every second they spend estimating is a second not spent producing value.

                        Also development is all about learning. If it wasn’t about learning, there would be a product on the shelf already. So estimates are going to be crud, your estimates of cashflow are going to be crud, committing to a plan is going to be crud.

                        So what really is the business value of these truly crappy estimates?

                        Alternately, you can point your devs in the most promising direction and get a tight feedback loop going verifying that it is still the right direction, and be prepared to change course.

                        As I opened with… Agile really had only one Big Point. The ability to change has high business value, so design your software and processes to be flexible.

                2. 2

                  In an ideal world we’ll all set our own deadlines, focus on what we think is right and would never be afraid to fail. And will still get paid for that.

                  1. 1

                    No, in the ideal world we would work out what is the minimum viable product that would leave the customer with something significantly better off than he is now…. And then get our heads down to deliver it working at full flow, at high quality, tested and in production ASAP.