1. 7
  1.  

  2. 6

    This feels more like an advert than an essay. Its terms are imprecise. What is “continuous delivery”?

    The job of a developer must focus on short and continuous delivery, to compete in that market.

    This sounds like a justification of the myopic, short-term management (“sprints” and “user stories”) that is killing programming.

    IT services evolved from being a cost center to being a company’s core, with software running the largest part of the business.

    No, that hasn’t happened at all. Technology gets the cost-center treatment more than ever. CEOs pay lip service to “technology” but it’s just a buzzword like “innovation” and programmers' social status has only gone down. Salaries have gone up for the mediocre, and a lot of unqualified people have poured into the field, but that’s only because of management types trying to commoditize programming talent (and failing at it).

    1. 9

      Disclaimer: I write the article.

      I have the feeling your comments are linked to the article you’ve published this morning (great article BTW).

      Let me be more specific on my thoughts: by “continuous delivery”, I mean repeatable processes for building and deploying software on servers, with short increments.

      We agree on how bad commoditization of workers is (nowadays with scrum, a few years ago it was other buzzwords, the core idea stays the same). Bringing Taylor-like methods to intellectual services professions (in our case developers) is bad for everyone.

      The commoditization I’m praising is not the commoditization of workers, it’s the commoditization of software. People will never be commodity, because talented individuals will always achieve more. A few years ago, when handwriting was still common, every good (or bad) author used a pen. The commodity is the pen, not the novelist. I think of continuous delivery and a good software factory as a pen, a tool for developers (good developers and bad developers alike). (To continue on the soft factory, developers are not meant to be factory workers, but factory designers).

      1. 1

        Thanks for clarifying. This makes a lot of sense.

        The commoditization I’m praising is not the commoditization of workers, it’s the commoditization of software.

        Good distinction. I agree. The code one writes is a commodity once it’s written. This is probably a big part of why open-source software didn’t ruin programming (as some feared that it would). People writing commodity code didn’t collect the rents anyway, so there was no benefit to the programmer in closed-source development.

        I think that part of our problem is that we’re seen as “producers of code” rather than as solvers of problems. Code isn’t innately valuable. Solving problems is. However, defining the job more broadly (a) brings many of us out of our comfort zone and (b) devalues executives, who sell themselves as problem solvers but can’t keep up with us on precision of thought.

        1. [Comment removed by author]

          1. 2

            do you see a lot of folks unwilling to engage in problem solving?

            Most of us only want to solve technical problems– not business or political problems.

            The rest of what you say I agree with.

            i suspect most of them view problem solving as some form of people skills combined with a wide network. “we need to deal with X? ok, i’ll call a guy.”, “ok, we’ll have a meeting and i’ll impress upon the staff how important it is that this be dealt with.”, or “i’ll throw some money at it.” bam, problem solved.

            This, and they’re also characterized by a severe imprecision of thought, which gives them a lot of confidence because they can always view themselves and their efforts as successful.