3 ms·
It's interesting to me that Parkinson's Law wasn't originally conceived of in the context of software projects, yet that's the only place I hear it applied toda
by ken 8y ago
It's interesting to me that Parkinson's Law wasn't originally conceived of in the context of software projects, yet that's the only place I hear it applied today.
I've been working outside of software recently, and noticed to my delight that this Law hasn't applied at all. In one case, I was hired for 3.5 days of work, and we got finished after 2.5 days so we were sent home early -- nobody was dragging their feet to make it last 3.5 days. In other cases (more common), we've temporarily had too many people for the job at hand, so the team lead said "Just wait", and we do nothing until there's more work ready for us.
Why have I never heard of any software team ever saying "There's nothing for you to do right now, so just wait"? My first thought was the endless supply of bugs, but that can't be right, because I've never heard of a team lead saying "We have no work for you today so go fix bugs for a while", either.
It really does seem like every software team manager thinks that the proper amount of complexity in a system is perennially $(current_complexity + 1). The cases where program complexity approaches a constant asymptote (like Redis and perhaps SQLite) are so rare as to be notable. They're also frequently mentioned as being developer favorites.
Maybe the field just needs another 50 years to mature.
- majewsky 8y ago> Maybe the field just needs another 50 years to mature. This thought is pretty obvious from my humble POV. Do we know of any field this extensive that matured (by any reasonable definition of "mature") in less than 100 years? Civil engineering took thousands of years to get to a point where it's not taken for granted anymore that the construction of a large building will cost the life of some construction workers.
- kough 8y agoI'd love to read a short sci-fi story about what it's like programming in a mature field. what problems will go away? which do we want to go away? (will people still use emacs?)
- ken 8y agoThe classic is https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff and it's sci but not fi.
- ken 8y agoSure. Powered flight went from "not invented yet" to "fastest and safest way to travel" in less than 100 years. Nuclear power has had a couple significant disasters but is otherwise mature. Antibiotics. Rockets and satellites (like GPS). Filmmaking. For the most part, I think major new inventions of the 20th century have taken much less than 100 years to mature. We have science and engineering now, so being able to apply them to new fields is generally feasible. I'd flip it around: what fields still have not matured yet? In what fields, since the dawn of science and modern engineering, is the median project still a failure? I'm hard pressed to think of any outside of software.
- majewsky 8y ago> In what fields, since the dawn of science and modern engineering, is the median project still a failure? Social sciences (the replication crisis).
- ken 8y agoTrue, but social sciences (at least many of them) definitely predate the scientific method. Also, observing that software engineering is not really doing much worse than social sciences at producing results certainly doesn't make me feel very good about software engineering.
- repsilat 8y ago> Why have I never heard of any software team ever saying "There's nothing for you to do right now, so just wait"? In addition to Parkinson's Law, there's this one: "A poem is never finished; it is only abandoned." There's never nothing to do, because we can always improve things. And to a business or to a manager, "just wait" costs about as much as "work on something of little importance" but provides less benefit. It might be different if programmers were all on zero-hour contracts. (OTOH... Firing engineers could work. I wonder why sites that seem "done" don't decrease their payrolls. Pride?)
- yourbandsucks 8y agoIndividual incentive. Every manager wants a bigger team and impactful projects for their resume. This bubbles up to the top, where rarefied execs don't see a reason to go to war with their own org and possibly lose. As long as it's still profitable, everyone's doing fine.
- ken 8y agoI disagree that "we can always improve things". That only works in a few fields. When Tom Wolfe was finishing up a new novel, adding more writers wouldn't improve the story. When a cancer patient is undergoing chemo, adding more physicians this afternoon won't improve the outcome. Adding cooks to the kitchen of my favorite noodle shop isn't going to improve the noodles one bit. Adding more actors to a film's shoot schedule isn't going to make it go any faster. In all these cases, even if you gave me 100 more skilled people for free for a week, I'd tell you that we don't need them, and it would actually hurt us for them to participate. Changing the plan or going off-plan has a real cost. Mature fields like civil engineering have a great track record because they don't just let extra people make contributions at any point in the process. BTW, according to Wikiqote, the correct (and unabridged) quote is: "A work is never completed except by some accident such as weariness, satisfaction, the need to deliver, or death: for, in relation to who or what is making it, it can only be one stage in a series of inner transformations." For programming to be a mature field, "the need to deliver" must be a necessary component, and "satisfaction" should be the goal, not merely an "accident". We can't utilize the process of a 19th century French poet and expect to get results like 21st century civil engineers. This was a guy who (according to his Wikipedia article), "around 1898, he quit writing altogether, publishing not a word for nearly twenty years."