1. 28

  2. 10

    In a burndown chart, I want to be able to run simulations as well. “What happens to this project if X work falls behind. What happens if Bob gets sick?”

    Is anything in software development predictable enough to make this kind of analysis useful?

    1. 8

      No, this is basically a management wish-fulfillment fantasy.

      Seeing that we thought something would take 8 hours of work but we spent 24 is incredibly valuable. We can revisit our assumptions we made when estimating see where we got it wrong. Then, we can try and account for it next time. Yes, estimating is hard but its also a skill you can get better at if you work at it and have support for proper tools.

      Likewise, I have heard this asserted by every manager I’ve ever worked with and for. No evidence has ever been presented, nor have estimates actually improved over time. (The usual anti-pattern is: estimates get worse over time because every time an estimate turns out to be low, a fix is proposed–“what if we do all-team estimates? what if we update estimates more frequently?”–which inevitably means spending more time on estimates, which means spending less time on development, which means we get slower and slower.)

      1. 7

        I personally used to be quite bad at estimating. I’ve worked at it, I’ve gotten much better about estimating. There are things you can do to get much better at it. None of the things you’ve mentioned are ones I think would help. I plan on writing a post about the things I’ve learned and taught others that have helped make estimates more accurate.

        1. 3

          That would make great reading.

          Are there any existing accounts of effective software schedule estimation you’d recommend?

          1. 1

            Two things I would recommend (and will be primary topics of said blog post).

            Estimates slipping is usually about not accurately accounting for risk. Waltzing with Bears is a great book on dealing with risk management. The ideas in it might be overkill for many folks but the process of thinking about how you should account for risk and establishing your own practices is invaluable. The book is great even if you only use it as “that seems overblown, what if I…”.

            The second is to record your estimates and why you made them. What did you know at the time that you made your estimate. Then, when your estimate is wrong, examine why. What didn’t you account for? When I first started doing this, I realized that most of my estimates were wrong because I didn’t bother to explore the problem enough and that I was being tripped up by not accounting for known knowns. Eventually I got better at that and started getting tripped up by known unknowns (that’s risk). I’ve since adopted some techniques for fleshing our risks when I am estimating and then front loading working on risks. If you think something might take a week or it might take a month, work on that first. Dig in to understand the problem so you can better estimate it. Maybe the problem is way harder than you imagine and you shouldn’t be doing the project at all. This isn’t a new concept but its one that is rarely used. In agile methodologies, its usually called a “spike”.

            I’ve worked on projects that spanned over the course of months and we spent a couple weeks on estimation and planning. A big part of that time digging in, understanding the problem better, discussing it and coming up with what we needed to explore more to really understand the project so we could course correct as we went along.

            1. 1

              Ooh, a DeMarco book! Will definitely check it out. Thanks!

          2. 1

            Please do write this, I need to improve in this area.

          3. 1

            The wish-fulfilment does not exist in a vacuum.

            Your customers might not be happy with your team constantly running late. Your pre-revenue startup might have a hard time raising investment. Whatever. There are external reasons for why a professional developer must be reliable in his or her estimates to actually get things out the door.

            I’ve been changing my opinion on this back and forth. Especially in a pïss-poor startup, where the the biz guys wanted us to skip unit testing to achieve results faster, refusing to estimate was a fuck you. The code base got convoluted, but also dealing with how they represented things was frustrating.

            I feel that in those cases the problem runs deeper in how geeks are supposed to be managed. Hell, it could be that estimation starts eating up time because the managers drove the geeks into protesting, which is - of course - as unprofessional as delivering late. Still you need to sort out your org for smooth ops before taking care of estimates.

            Yet this isn’t car repair for old vehicles, where you find more and more problems as you go along, making estimates tough without thorough diagnostics, but the customer is happy with the substitute car you gave out in the meantime.

            1. 0

              The fact that customers want something, or that it is necessary to the business’s success, do not cause it to become possible. I’m not disputing the desirability of accurate estimates. I’m disputing the idea that they are possible. I have not seen any team or technique generate such estimates reliably, over time, in various circumstances. (Of course, like any gambler with a “system,” sometimes people making estimates get lucky and they turn out to be right by coincidence.) I have heard many managers claim to have a system for reliable estimates which worked in some previous job; none was able to replicate that success on the teams I observed directly.

              (It’s not just software, either. Many people point to the building trades as an example of successful estimation and scheduling. In my experience maintaining and restoring an old house and the experiences of friends and acquaintances who’ve undertaken more ambitious restorations, this is more wishful thinking. It’s common for estimates by restoration contractors on larger jobs to be off by months or years, and vast amounts of money. If so mature an industry can’t manage reliable scheduling, what hope is there for us?)

              Yet this isn’t car repair for old vehicles, where you find more and more problems as you go along, making estimates tough without thorough diagnostics, but the customer is happy with the substitute car you gave out in the meantime.

              I’d argue that is exactly what much software development is like (except there is no substitute for the customer).

              1. 1

                Maybe I’d like to be more optimistic about learning to estimate better ;) But for sure @SeanTAllen touched on a lot of pertinent points. Is it Alice or Bob who gets the task? How well is the problem space, the code, known? And so on.

                It’s hard as balls, and you’re not wrong with your gambler analogy, but not all systems for getting things right occasionally are equally unlikely to succeed. Renovators also learn what to look out for and how long those issues tend to take, as well as the interactions. Probabilities are usually ok by customers if that’s all you got.

                In my car analogy, the point kinda was that we’re screwed because we can’t give out substitutes. We can deliver temporary hacks, although nothing is as permanent as a temporary hack.

          4. 1

            A lot of activities in software development try to improve predictability. For example: following style guidelines, continuous integration, unit testing, etc. All of these have a cost and slow developers down. The upside of course is to reduce bugs which will slow you down much more later. Or maybe not. The risk is generally too high, so we generally prefer the predictability of a slow incremental process.

            I have a feeling that Demings thought about that when he talked about “variation”, but I need to read more from the father of Lean and grandfather of Agile to understand that. Currently, I believe that I don’t assign quite the correct meaning to the words I read from him.

          5. 9

            Honestly, the tool I’ve seen come closest to this list of requirements is TFS, rebranded as Azure Dev Ops. It has a lot of estimation tools, code artifacts can be linked to issued, it has a competent git hosting platform with Pull Requests, and so on.

            1. 1

              I second this, TFS is amazing.

            2. 7

              These are nice, but to be fair, I think when most people want this level of management, they start using Jira or likewise.

              1. 1

                Yes, JIRA does do all of the things mentioned in this article if you count in the various plugins like Agile and Tempo (time tracking)…I think the only thing it can’t do are “confidential issues”, you’d have to make the whole project private IIRC.

                That said, the tools that JIRA delegates to like Stash and Bamboo leave a lot to be desired. We’re sorta tearing our hair out with Bamboo’s inability to have reconfigure builds (like with a .bamboo.yml file) on a per-branch basis.

              2. 6

                The problem with issue trackers is that the intersection of everyone’s “wants” is something simple like GitHub Issues.

                1. 1

                  And things more complicated than Issues look and feel more complicated too, and then you just want X but easier to use.

                2. 6

                  For a unified tool that’s got deep project management, artifact hosting, code review, etc, check out Phabricator. I haven’t used it seriously, but it seems to offer a lot of your asks. Gitlab is also getting close, withintegrated CI tools and now “serverless” … something, large file storage, and more flexible issues.

                  As far as Github goes: why not a Github for code, CI (using Actions), and artifacts, and a separate “tasks” tool for tracking projects, issues, notes, meetings, etc? Jira for instance provides all the desired features listed for issue management. There’s a pretty good integration between Github and Jira which lets you creat references between the two systems, like importing GH issues into Jira, and closing Jira tickets with GH pull requests.

                  1. 5

                    The issue with Jira is that it’s kind of horrible. It loads incredibly slowly, with widgets which continue popping in and moving stuff around even after the main html is loaded, and its UI is confusing and overly complicated and sluggish (even after everything has loaded) imo.

                    1. 1

                      Jira is very customizable and frequently installed “on-prem” by organizations, so your experience with it depend a lot on how your org sets it up. At my most recent job Jira was everything you describe, but I’ve also used a hosted instance with many features and fields removed by the default org configuration that felt light-weight and low mental burden.

                      My point stands however you feel about Jira: sub Request Tracker or any other full-featured “agile” ticketing system above.

                    2. 5

                      I came here to vouch for Phabricator. I’ve used it, on and off, for almost three years and it’s a joy to work with. Using Github was dreadful after I started using Phabricator.

                      Gitlab is, I believe, a “safer” choice over Phabricator, in the sense that there’s a multimillion VC-backed company behind it, dozens or hundreds of employees etc, while Phabricator is currently at a smaller scale. But philosophically speaking Phabricator is truly open source while Gitlab isn’t, and that alone wins me over.

                      A new, more hard-core contender is sr.ht. Unfortunately it’s still too raw for me, but it’s worth keeping a tab.

                      Anyway. Highly recommend Gitlab or Phabricator over Github. It does solve many (not all) of the issues listed in the article.

                      1. 3

                        FWIW GHC (Haskell) is moving from Phabricator to Gitlab

                        1. 1

                          I feel like there are two less-than-ideal options on that one. Phabricator is incredibly fast, but I think the complaints in that email are legitimate (development priorities are odd, and open-source friendliness definitely seems on the decline). GitLab does tons more and is more responsive, but it’s also just so damn slow. This morning, I checked out their about page again, and it reliably took nearly a second to render on my iPad. That’s just ridiculous.

                          I’m optimistic Phabricator will add burndown (or, even better, burn-up) tracking before we really need that kind of view, but if not, GitLab may be the only legit option.

                    3. 4

                      That got me thinking, what are some of the other things I’d like to see in a GitHub.

                      The thing I’d like to see from GitHub is make it as easy to donate to a project/person as it is to fork it.

                      1. 3

                        After years of being a github fan, never thought it was possible to migrate away, but after using gitlab over a year, github feels so lacking. Gitlab has so much more: CI, integrated docker registry, good issue tracking with milestones, great search and a good community. Also I value their transparent company with visible milestones and upcoming features and releases.

                        On github I always hated how hard it was to scope the search to some organization, this filtering was hidden way too deep to the advanced search page.

                        1. 2

                          I have not tested Basecamp in many years, do anyone of you have experience with their product?

                          Their list of features seems very focused on getting things done and only requiring input when it is useful to someone: https://basecamp.com/features

                          Their hill charts, with time travel-like snapshots would maybe help set the confidence level.

                          1. 1

                            due date and “sort by due date” in the issue list sounds like a feature with a very high bang for the buck. combine that with confidential issues and you have a quick built in prioritisation tool and todo list for project collaborators at the cost of (yes, oversimplifiying a great deal but…) two database columns and a bit of UI work.

                            1. 1

                              Honestly after going through a lot of “thought management” software, I’ve really just stuck with checkvist.
                              It’s keyboard driven, which makes navigating it a lot easier.
                              This is starting to sound like an ad, but it has helped organising everything.

                              Arguably, it’s probably more of a personal manager than a team one….

                              1. 1

                                Checkvist seems cool, but it’s a) personal and b) not free, limiting its reach (but I wish them luck!)

                              2. 1

                                If anybody applies (all) these features on its project it’ll start to feel like a work. They’re good indeed, but also adds some complexity for maintainers and people who only wants to contribute.

                                1. 1

                                  Most of this wishlist sounds reasonable (although I’m a little skeptical of some items) but I would be sad to see it end up implemented in Github Issues. I actually really like GH issues precisely because it’s bare bones. As someone who runs projects that tend to have between one and five contributors it works great as an easy todo list that facilitates discussion of issues. As an irregular contributor to a number of projects (i.e. submitting a bugfix or minor feature add to projects I use as my use case necessitates, or just in filing bug reports) triage systems and work estimates and kanban boards are all a big pain in the neck, the only thing I really need to know is “does a ticket for this exist yet”.

                                  I get that these things are useful, but I’d rather let the default GH issues system be as simple as possible and let third parties offer software for more complex use cases.