Yes Silver Bullet (2019)

110 pointsby wheresvic3over 5 years ago

16 comments

pronover 5 years ago

Here's the problem, though. Brooks made a certain observation about accidental vs. essential complexity; the author of this post makes another. Brooks made a certain prediction based on his observation (diminishing returns in impact to productivity), and many believers in the power of programming languages found his prediction to be too pessimistic at the time (he lists their objections in "No Silver Bullet, Refired"). Only it turned out that his prediction was correct, except it was too optimistic. So if anyone wants to claim that his observation was wrong, they would need to explain why his prediction turned out to be true, while that of those who believed it was wrong turned out false.In addition, I agree with the author that the biggest contributions to productivity we have seen were, in this order, the availability of open-source libraries and online forums, automated testing, and garbage collection -- all of which have been adopted at rates we'd expect from adaptive traits in an environment with selective pressure. What is conspicuously missing is linguistic features, also in line with Brooks's observation. And yet the author still claims that linguistic features are the silver bullet. At this point this qualifies as an extraordinary claim that requires extraordinary evidence, but I would settle for ordinary evidence, which is also lacking -- strange, considering that a silver bullet, i.e. something with an extreme bottom-line impact, should be easily observable.

评论 #22138882 未加载

评论 #22140815 未加载

评论 #22139471 未加载

评论 #22139134 未加载

评论 #22145439 未加载

评论 #22138609 未加载

benjaminjosephwover 5 years ago

This is a really interesting take on the Silver Bullet argument - Brooks is right that big gains in productivity are only gained by reducing accidental complexity but he was wrong about how much accidental complexity there still is to reduce.I think most Software Engineers probably suffer from some cognitive bias in trying to estimate exactly how much accidental complexity exists that could be eventually removed. We tend to think about incremental improvements to tools and processes rather than thinking at a higher level about improving the overall process of translating business requirements into working software. Even with much better tooling and languages (i.e. #F, Git, AWS, etc) there's still a lot of fat that could be trimmed.I'm excited to see what the wold of low-code will do to our current assumptions about how much accidental complexity there actually is. Maybe projects like Dark[1] could actually achieve the order-of-magnitude gains that Brooks was convinced wouldn't be possible. Sure, there's no panacea, but maybe we're round the corner from a genuine "Silver Bullet" in the sense that Brooks actually meant.[1] - <a href="https://medium.com/darklang/the-design-of-dark-59f5d38e52d2" rel="nofollow">https://medium.com/darklang/the-design-of-dark-59f5d38e52d2</a>

评论 #22140077 未加载

bcrosby95over 5 years ago

I'm in Brooks' camp. I see mostly essential complexity. There are problems we've been pounding on for a decade that have solutions that are mostly essential complexity. Then people come in and create pointless requirements that turn that fairly simple essential complexity... extremely complex.I think the modern problem isn't accidental complexity, it's essential complexity that isn't actually necessary for project success.

评论 #22139125 未加载

评论 #22139528 未加载

评论 #22143102 未加载

goto11over 5 years ago

Brooks defines a "silver bullet" as a single technology or tool which yields a 10 times increase in productivity across the board. In other words, a "silver bullet" have to eliminate 90% of all the work a developer does during a workday.But a typical developer is not even coding half of the time! They are discussing with the product owner to clarify requirements, reading specifications, writing specifications, thinking, surfing Jira etc. A lot the work of a developer is to take vague requirements and transform them into unambiguous language. These are effects of the inherent complexity of software development. And then we have stuff like researching and evaluating what framework or library is the best fit for a given task.Haskell is cool and all, but it will not eliminate 90% of what a developer does in a day. No single programming language, however perfect, will.

nayukiover 5 years ago

The section "Accidental complexity abounds" and the diagram is reminiscent of a Twitter thread last month:<a href="https://twitter.com/gravislizard/status/927593460642615296" rel="nofollow">https://twitter.com/gravislizard/status/927593460642615296</a> "almost everything on computers is perceptually slower than it was in 1983" ; <a href="https://news.ycombinator.com/item?id=21831931" rel="nofollow">https://news.ycombinator.com/item?id=21831931</a>

评论 #22140213 未加载

haddrover 5 years ago

I think Brooks is still right and what author mentions is not one thing but a set of practices that became proven enough that became almost like a standard approach in software development. And they provide some productivity gains if we compare how software was built 50 years ago. Yes, the difference is big but we forget that all those things were introduced incrementally and in the course of decades. So yes, together they make a huge difference but they haven’t appeared in one day.

评论 #22138102 未加载

评论 #22138166 未加载

mikeceover 5 years ago

The difference between accidental and essential complexity cannot be underscored enough. Removing accidental complexity, even if it flies in the face of "best practices," can be very powerful and appropriate as long as it's understood where you are intentionally coloring outside the lines and the conditions under which you'll need to revert to best practices for scaling up.An example: I attended a conference presentation in which the presenter discussed dissecting the implementation of Identity Server into a dozen sub-services with half a dozen backing data stores with Redis caching layers and an Event Source model for propagating inserts and updates of the underlying data. This would be a prime example of accidental complexity gone wild if you built this just to have a multi-container microservice -- unless your single-signon service as a whole needs to support 100MM+ users, in which case this is essential complexity, not accidental.Reducing accidental complexity but being mindful of how it could become essential complexity under certain conditions in the future is the mark of a wise architect, IMO.

Koshkinover 5 years ago

The progress in tooling and methodology is paralleled by ever increasing complexity of software and problems it is solving. It's a zero-sum game. Still no silver bullet.

评论 #22138200 未加载

评论 #22138414 未加载

mkarlinerover 5 years ago

I think the points about accidental vs essential complexity are well made. However...The title/s are about Silver Bullets, and I strongly do not believe in them.I've been programming for an embarrassing number of years, and I've seen methodologies come and go. Increasing productivity is about developing a good team culture with a small number of simple tools, not about following the latest Silver Bullet.In fact, it's very easy to increase the level of accidental complexity by adopting an overly prescriptive or complex tool/methodology (Jira anyone?).

评论 #22139889 未加载

daotoadover 5 years ago

The only way we'll see real 10x improvements take hold is for our discipline to mature. As long as we are experiencing high rates of growth, where all it takes is 3-5 years to become "senior", while the voices of the real senior developers are swamped by hordes of newer devs, we will wallow in inefficiency and fail to improve much.Most of the accidental complexity I see day to day comes from slow accumulation of errors in craft. Need to validate that an ID is a least plausibly valid, "I'll just match it with a regex here", and in 27 other places in the code, each one added in a different sprint. Little things like referring to data that is passed into an api with the variable name "json" when it is really a data-structure that was parsed from the body of an API request. Is this thing I am manipulating a "tab", a "filter", a "type selector" or a "group"? When methods and variables use a mix of conflicting names for the same concept.Until we learn, as a profession, that shipping working code is not enough, that our code must clearly, concisely, and consistently communicate the core concepts embodied in the program, accidental complexity will bury us.

JackRabbitSlimover 5 years ago

I would argue that a good chunk programming tools don't reduce complexity at all. Just shifts it to well understood "accidental" complexity.Your program needs a way to store and retrieve key:value pairs. It's an inherent complexity your program requires. You solve it by using an industry standard product like Redis. Now your code doesn't contain any key:value logic itself! complexity avoided right? Nope just shifted and doubled or trippled in size to boot. No KV logic but now you have to have db libraries, parameter parsers and sanitizers, sockets between services, etc, etc, so on, and so forth.It's well trod ground, your IDE will generate 90% of that type of code for you. you throw a library or template or whatever at it and go about your day.Software isn't just your code. Now your application that needed K:V storage has the entire bug and exploit surface area of your code and Redis. Do this 20, 30, 100 times with other libraries and packages. Each time your code gets a little smaller, a little slicker looking and the actual running software is an unholy monster spread across an entire server cluster. Oh well, your code is clean and tidy.

rsclientover 5 years ago

What I dislike about all Haskell examples on every blog is that the writer happily assume that I'm familiar enough with Haskell syntax to understand the code.In the ordinary method, there's a function name, it takes one input, and returns a result; easy-peasy. Yse, what the method does isn't clear, but at least I know the methods name!Now lets look at the Haskel fuction. tryAccept :: Int -> Reservation -> MaybeT ReservationsProgram IntI've read enough of these Haskel enthusiast blogs to know that the name of the function is tryAccept (it helps that it's the same as the C# method), and it takes in two parameters, an int and a Reservation and returns a Mayb of a ReservationProgram. And it's somehow an int, so it's like an enum? That's weird, clearly I don't understand Hasket syntax.And then later, I'm told that it's simple to figure out what a ReservationsProgram is because there's some enum that doesn't include the word "ReservationProgram" in it.No offence, but this isn't enticing me to Haskel.

skywhopperover 5 years ago

So, the author here is arguing that between ready reference/help on the web and TDD, that programmers today can be _100x_ more productive than they were in the 80s? Add a dash of strongly-typed functional programming and we can be 1000x more productive?I agree that these tools can be productivity enhancers, but if that factor is even 10x that would a huge claim, much less 1000x.

评论 #22145298 未加载

ncmncmover 5 years ago

It's a shame that the author blows his credibility asserting that garbage collection reduces accidental complexity, because he is right that the amount of the latter really has been much larger than Brooks estimated.If you have ever watched the hoops somebody jumped through to plug a memory leak in a Java program, you will be forced to agree.A fundamentally very similar process appears as a functional programmer unravels a program to fix a performance bottleneck. The reason it is similar is that, just as ballooning memory usage indicates a memory leak, a ballooning runtime indicates a time leak.And, just as GC languages provide inadequate facilities to manage resource use, functional languages provide minimal resources to manage time use.You could argue that memory and time management are on the accidental side of the ledger, and while the scientist in us would be tempted to agree, the engineer knows that managing limited resources is the essence of engineering, and taking away the tools needed to manage resources makes resource problems balloon out of control, breeding extremes of accidental complexity.

评论 #22141465 未加载

pjmorrisover 5 years ago

This might be just me, but Brooks explicitly put a decade time tag on his 1986 prediction, complicating the authors's comparisons from ~three decades later. I guess the way to tell would be to have people or teams build examples of 1986 level-of-complexity software and see how long it takes them.

评论 #22138422 未加载

kerkeslagerover 5 years ago

> Ostensibly in the tradition of Aristotle, Brooks distinguishes between essential and accidental complexity. This distinction is central to his argument, so it's worth discussing for a minute.> Software development problems are complex, i.e. made up of many interacting sub-problems. Some of that complexity is accidental. This doesn't imply randomness or sloppiness, but only that the complexity isn't inherent to the problem; that it's only the result of our (human) failure to achieve perfection.> If you imagine that you could whittle away all the accidental complexity, you'd ultimately reach a point where, in the words of Saint Exupéry, there is nothing more to remove. What's left is the essential complexity.Okay, that might be a useful way of thinking of things...But the author then goes on to talk about how he thinks that Fred Brooks underestimated the percentage of accidental complexity in the average project.However, he then starts to go into things he thinks are "silver bullets", but most of them are tools that, in my opinion, address essential complexity:* The World Wide Web: in his description, this solves a problem of the complexity of finding how to do things. Can we imagine a solution where finding out how to do things isn't part of the system? No? Under the definition, that's essential complexity.* Git: in his description this solves the problem of tracking changing source. Can we imagine programming where we don't need to keep track of what source changes happened? I can, maybe, in a distant future where programming is done an entirely different way, but I'd argue that at that point it's not really the same problem. If we're writing code to solve a problem, then tracking changes to that source is essential complexity within that solution.* Garbage collection: again, maybe there will be a computer that works completely differently (quantum computers?) but under current architecture, the physical machinery of a computer has limited space, so we need to reallocate memory that is no longer being used. That's not accidental complexity, that's essential complexity. There are other solutions to this, but every program solves it in some way, whether it's by reference counting, manual allocation, borrow checking, preallocating everything, or just allocating everything on the stack and copying everything, and each of these has complexity: that complexity is essential.I think what this all points to is that essential complexity isn't intractable: you can make it someone else's problem. In these cases, we're taking some part of the essential complexity of solving a problem, and letting our ISP and websites solve it, or letting code that we don't maintain solve it. Some of the most powerful tools are ones that solve a form of complexity that is essential to a wide variety of problems.