4 ms·
Whenever I read something like, "Software development is not carpentry. Almost everything a developer writes is unique, they have never built that particular th
by r_hoods_ghost 4y ago
Whenever I read something like, "Software development is not carpentry. Almost everything a developer writes is unique, they have never built that particular thing before. We are not cabinet makers repeating a variation of something we've built hundreds of times before." I just assume that the person is trolling, or a child.
Virtually all software developers are building minor variations on thing that have been built hundreds if time before. Sure, maybe not by that particular software developer, but by a thousand others at some point, and half of those have probably stuck their code on GitHub so you can look at how they did it.
This idea that software developers are somehow cranking about beautiful snowflakes of such uniqueness that it is impossible to ever estimate how long something will take is nonsense. It is delusional.
I really wish as a profession we could get over ourselves and acknowledge that, hey, it is possible to learn from others, that much of what we do is repeatable, and that if you're really struggling with estimating it probably isn't because you're engaged in ground breaking work that has never been done before, but rather that you haven't bothered to think things through.
- Groxx 4y agoI generally think the plumbing analogy is a pretty good one. It even works for estimates! We're often asked the equivalent of "how long will it take you to hook my sink up to my toothbrush for my Thursday home parties" and... well it's nothing new. It's just pipes. Anyone can do it. But estimating it requires an absurd amount of context which is not always available. How far apart are those two things? Is there enough water flow to power the toothbrush, or will you need to upgrade the piping to the sink too? Sometimes the house has everything made of marble and it'll cost millions of dollars to replace the holes you need to make to put those pipes in, though piping itself is only like 30 minutes. Sometimes the toothbrush is a legacy model that only works with deionized water from Uruguay that has been flown within 50 meters of the south pole in the middle of March, do they have a reservoir available for that or can you convince them to just buy a modern one from Walmart to replace it? Does a DWUSPM50 water supplier even exist any more? Oh, you meant only during those Thursday parties? Is there a way we can tell when those are happening, or can they just pull on a lever to change the system? Does GPRD require the pipes to physically separated by 1m when turned off, or is a valve good enough? Why in the world does the customer require all horizontal pipe runs to only go North unless they're underground? None of which is hard, and the plumber doesn't have to build it all in many cases. But how long is it going to take? .... somewhere between an hour and the end of the universe, most likely, unless there's proof the request is impossible. It's not a perfect, beautiful snowflake, but it is a snowflake.
- bbojan 4y agoYou're saying we've been calling it "Software Development" in error, and it should really be called "Software Production"?
- lossolo 4y ago> Virtually all software developers are building minor variations on thing that have been built hundreds if time before. Speak for yourself. I build distributed systems and unique solutions that you can't find anywhere open source, which makes estimating very difficult.
- tailrecursion 4y agoExactly. Many commenters are making up rules for software engineering and think the rules ought to apply universally.
- barrysteve 4y agoScrolling through a thousand others' code on GitHub, is not what a cabinet maker does. You want a standard for all programs you could build, put it in the CS degree or a 1 week training course that gives you a license at the end. Like a forklift guy goes through and happens to come out the other side knowing all the basic rules. The forklift guy doesn't have to scroll through thousands of GitHub projects to infer from studying, what could be taught in a week with some decent management and/or training. When there's no standard, literally of course everybody's a beautiful snowflake who comes to their own conclusions. We have trained people to be that. Of all the suggestions I could make why not cut to the deepest one. We're not going to have standard programming patterns understood by your average-joe-coder fresh out of university, until those patterns have been integrated into the English language like Greek drug terms and Latin legal terms. You can learn and build a entity component system for a video game in a week, come back after a month of exciting holidays later, and discover you've forgotten what an ECS even is. But the biological concept of evolution (or contract law, or anything else) is learnt-once and stays with you forever. It's time that the basic programming concepts have fixed names that don't change. That are embedded in the English language, taught at school from grade 0 and are distinguished from normal English words with some ancient-yet-familiar dialect. Ancient Americana if it were possible. I'll make a standard. The next generation of children won't even realize they already know "how to program" by the time they are 9 years old, and they won't argue about the existence of these concepts, nor forget them, they'd just argue the style of them. We'd skip generic English words like "game loop" and acronyms like "ECS" and have real identifiable phrases in a familiar-but-old language that refer to powerful concepts. /soapbox
- wvenable 4y ago> Virtually all software developers are building minor variations on thing that have been built hundreds if time before. I've never written a piece of software that has already existed that could do the job -- why would I -- that's why we have a thriving software market of purchasable software. The market of reusable software is massive. > This idea that software developers are somehow cranking about beautiful snowflakes of such uniqueness that it is impossible to ever estimate how long something will take is nonsense. Your argument is that you can estimate minor variations. But how do you know the consequence of adding feature X is a one hour job or a one day job? If you have 50 minor variations or 500 minor variations that are each maybe one hour or one day jobs, how long is that project going to take? I've got a unique snowflake here. In most other industries, they can estimate quite accurately because they've spent the time planning all the details. The cost of construction and labor absolutely dwarfs the cost of planning. With software, the planning is the entire project. The closer the plan is to covering every single possible case, the closer the software is to being done.