1. 22

  2. 14

    Also see the well-established Iron Triangle: https://en.wikipedia.org/wiki/Project_management_triangle

    The premise in this article uses Time and Money and Quality as parameters to success - but is missing Scope. In the iron triangle, quality is not a parameter, it is a function of schedule, cost, and scope.

    Presumably this is valid if there is no scope for a project, but I am skeptical. Since if there is no finite list to account for (even if created in iterations/sprints/whatever), there is increased chaos. With chaos comes side effects (confusion, over-reactive tendencies, motivation loss, etc). Startups are chaotic to be sure, but would this omission push them over edge to being unfocused and unable to deliver effectively?

    With that nitpick out of the way, I do enjoy the rest of the article. Software is a creative process. Those that operate under the basis that it is purely quantitative and technical and rigid, are going to experience frustration. Experience will teach one this over time, and it cannot be forced. A time-learned team will be much more efficient, and the cost balances out with more people being happy and dedicated, and less frustration along the way.

    1. 12

      I like how the article notes one of the main sources of burnout in senior engineers: continually cleaning up messes caused by other people.

      However, I think that it does miss the biggest pathology of engineers–a continual reinvention of shiny and experimentation that I can only describe as neurotic. Watching engineers throw away perfectly good tooling in order to try the framework of the month reminds me of a cockatoo plucking its own feathers out because it isn’t getting to do anything fundamentally interesting in its cage.

      Companies have this problem where they refuse to acknowledge the commonalities that their businesses have with every other business on the planet (and hence they won’t accept standardized solutions) and also where they won’t actually pay engineers in such a way as to reward them for delivering value on time and under-budget.

      I ask you fellow lobsters–if you were guaranteed 1-5% of growth profits that your company had this year, how much harder would you work? How much less would you invest in new toys?

      Similarly, if there is no further growth, maybe it’s time to stop writing software. Maybe the business is completed, and we can all go do something else rewarding with our lives.

      1. 5

        Similarly, if there is no further growth, maybe it’s time to stop writing software.

        I think there’s also an important detail: the job isn’t to write software. It’s not to ship things. It’s not to fix bugs.

        The job of everyone is to do the “right things” so the company can make more money/be more sustainable/whatever the final goal of the company.

        Sometimes this means not goofing off on rewrites. Sometimes it means killing off a project because this isn’t actually important. Sometimes it’s not even about technology. If you’re sitting around making store page updates but company logistics are causing your company to lose shipments, maybe you need to go help the mailroom.

        This is why I love having engineering handle user support. It helps teach you that shipping doesn’t mean anything if your old stuff is breaking. It teaches you that you’re not doing things in a vacuum. And it helps engineers also realize that results matter, and software development is just one piece of that.

        A lot of product teams build out these huge product plans, but in the end spend half of their time in “firefighting” mode. Most of those teams should immediately drop everything and…. just fix their stuff. Nothing else matters.

        Whenever you end up spending a bunch of time on things but it doesn’t seem to have an effect on the bottom line, it weighs on you. If you can get out of the box of your job title, though, you can go immediately towards fixing the things that need fixing, adding the things that need adding. And if you’re right, you will know, and you will know immediately.

        1. 4

          “However, I think that it does miss the biggest pathology of engineers–a continual reinvention of shiny and experimentation that I can only describe as neurotic.“

          We agree on this idea, that software engineering seems to operate in circles. Fundamentally, there is not much change happening: just new layers or ways of expressing. Each has its positives and negatives with respect to expressivity. For example, where first-class “objects” in object-orientation could help model concurrency and interactivity, now futures in event streams seem to be it all. The underlying model of concurrency has however not fundamentally changed for 40 years, and will unlikely change in another 40.

          Sometimes I am concerned, when discussing programming with fellow students who seem to be dissatisfied with extremely simple programs, that we learn to expect complicated solutions everywhere. In reality, only simple solutions are really solutions in the literal sense: a solution dissolves the original problem into understandible and simpler terms. The simpler terms allows one to perform a computation more easily, thereby tackling the original problem. I am not talking about algorithmics here, e.g. divide and conquer, but modeling humane computational problems.

          I would be even inclined to believe that too much focus on the programming activity actually distracts from solving any problem. Keep programming activitities at minimum, focus on the humane part of development of a project. Learn as much as is possible, or as much as one wants, from the problem domain. Attack small problems first, built it out into an ecosystem of solutions. Validate the solutions: try to explain peers what is the problem, why it is important and how it can be simplified. These solutions live in the minds of people within an organisation. Develop training programs to effectively learn new hires the legacy of the company comprising all existing ideas and ways of thinking.

          Most people equate the role of developer and programmer. That is wrong. Project development is people-first, machine-second. Now, the word “neurotic” perfectly fits this description in my mind: people problems can not be solved by thinking like a machine.

          1. 3

            The evidence to say that money movitvates (see https://hbr.org/2013/04/does-money-really-affect-motiv) is not strong, so the guaranteed bonus might not have an incentive effect…