Do we really have to? I think we all get the point.

The shed example above is of course taken to extreme. I see it more like choosing from a pre set choice of shed shapes, or sawing up planks yourself to make the shed whatever shape you wish personally.

Do you go to the local building materials supplier and pick up standard framing lumber and sheeting materials, or do you go into the forest with your axe and chainsaws? Or do you order a prefab unit and have it dropped off later that afternoon all ready to park your lawnmower in?

What if the prefab unit is too big, so it doesn't fit in the yard at all or eats up space that I'm using for something else?
What if the prefab unit is too small, so I can't fit all my tools in it?
What if the prefab unit is ugly plastic and difficult to maintain? Down goes the value of my property, whereas if I'd chosen to build a nice-looking wooden shed myself (or for that matter have a contractor do it), then my property value goes up.

What if the prefab unit is too big, so it doesn't fit in the yard at all or eats up space that I'm using for something else?
What if the prefab unit is too small, so I can't fit all my tools in it?

Then the available off the shelf solutions don't meet your requirements.

What if the prefab unit is ugly plastic and difficult to maintain? Down goes the value of my property, whereas if I'd chosen to build a nice-looking wooden shed myself (or for that matter have a contractor do it), then my property value goes up.

If you have the time, inclination and skills to build a shed, that's fine. But what are you sacrificing to do that? You might have a really nice shed in the garden, but maybe your house price is still in the toilet because you wasted your time building a sweet shed instead of doing the essential foundation repair work.

If you got a contractor to build you a shed, that might be a good solution. Maybe the contractor has specialist shed building equipment and can build a shed cheaper and quicker than you can.

It's all subjective, and it's all context dependent.

The problem with a lot of developers is that they look at a shed and say "I'll need some a hammer for that", and they set about trying to forge a hammer, instead of using a perfectly good existing hammer. Meanwhile, your neighbour has already finished his shed and is having a BBQ in the garden.

The point of my previous post was that there are many different ways that you can achieve the same end result: A perfectly functional shed that does what you need of it. The real question that you have to ask yourself is: What route to the end result is actually going to be the most effective for my project?

The up front costs of wandering into the woods with an axe as the way of starting your project is next to nothing compared to what it is going to cost to have someone bring a truck and crane to plop down a pre-made unit, and there are lots of excellent pre-made units out there on the market that will meet all kinds of demands on them. However what you save in up front costs is quickly going to run into the cost in time and effort of doing everything yourself. If you're not careful then you're not only going to spend more on the project than you would have by using a pre-fab, but you're also going to be out a hell of a lot of time that could have been used for other things.

Project development is about compromises and careful consideration. What are the actual goals? If your goal is to write code and learn technical details, then by all means, fill your boots and reinvent the wheel, the fulcrum, and the lever, but if your goal is to complete a task and get a job done, then you're going to have to be far more careful with how you go about your project if you want development to remain efficient.

Also, I'm the kind of person who would rather enjoy heading out to the woods with an axe and saw to start a building project for myself. Working with stuff like that is just something I happen to enjoy, but it isn't the route I would take if I have dozens of clients who all need new sheds before next weekend's storm.

Also, I'm the kind of person who would rather enjoy heading out to the woods with an axe and saw to start a building project for myself. Working with stuff like that is just something I happen to enjoy, but it isn't the route I would take if I have dozens of clients who all need new sheds before next weekend's storm.

Agreed, and sorry if I sounded snappy at you. TD's threads on these subjects always seem to end in disaster for some reason. There's this sort of implied subtext going on that those of us that invested decades in developing lower level skills were mugs who wasted our time.

After I'm familiar with the language/API, experience has taught me in general it's faster to write stuff myself than take the time to: a) download/install a library; b) uninstall it and download/install it again because I got the wrong version the first time; c) read the documentation (if it exists); d) implement something from the library which then doesn't work as expected; e) re-read the docs and debug the code; f) repeat steps d) and e) at least a couple times for each new "thing" I want to do. Etc.

This definitely rings true for me. I'll take starting from scratch, or at least at a lower level, any time over configuration hell. You know, where you have five xml configuration files in various places, each serving different undocumented but important purposes, leading to a perpetual cycle of death of googling outdated information, making a small change to your work, waiting 5 minutes for the change to be applied, and then seeing no change in behaviour (the occasional small breakthrough every few hours, followed by the "why isn't this in the documentation" rage) and back to googling using whatever debug info you got out of the previous attempt.

Libraries are awesome when they are well-designed, and I'll be the first one to suggest a library or framework that I find appropriate (when I have a choice) especially at work. Unfortunately, many popular libraries are fucking terrible and I'm finding myself spending more time reverse-engineering their internals than actually using them. Maybe I'm an idiot, but I think there are a lot of programmers out there that could use a little dose of lower-level design instead of piling up layers upon layers upon layers of conceptually challenging and poorly designed abstraction on the (easy) problem they are solving. That's why I'm so picky with the tools I use; the technical overhead increases unbelievably quickly if you pick bad ones.

Developing low level code skills is not remotely a waste of time, and it is an important part of coding that everyone should understand even if they're not planning to use it often or develop really strong skills in it.

However I've met far too many programmers, especially those who are under 30, who insist that they are awesome and amazing, and that their code is automatically better than code written by people with decades more experience than them, and that all of their projects must be written from the ground up and that having third party code included in their projects will somehow taint them.

Doing it all yourself might be great when you're only dealing with short university projects, but dear god that kind of attitude is painful when you are out trying to develop software for profit. I've watched half a dozen promising startups fail in the last four years because of these kind of attitudes. Companies started by "Gods" who could do no wrong, who turned one of their university projects into a business asset, and then insisted on doing everything themselves. Two years later one of them still hadn't shipped their product because they had just spent the last six months trying to fix their horribly broken homemade networking API (Which did nothing new, unique, or remotely interesting over any of the popular third party ones which, you know, actually worked...) and they ran out of money and all his former classmates who started the company with him jumped ship to take other jobs.

Long story short: Pick your battles carefully when it comes to developing software. Learn what tools are open to you, and use them wisely.

Agreed, and sorry if I sounded snappy at you. TD's threads on these subjects always seem to end in disaster for some reason. There's this sort of implied subtext going on that those of us that invested decades in developing lower level skills were mugs who wasted our time.

These threads are for educational reasons, as I am trying to learn and teach programming to people who have no idea about the idiosyncrasies involved in this field . Most of my threads are reference for myself and those who come after me who may have the same questions (as I do).

I want to see the advantages and disadvantages of "from scratch," most of which I have already experienced. The answers here are always diverse and complete. Usually when it gets to that point (hopefully without disaster), the tread usually ends, and it serves as a nice archive for me and others to reference.

There is just one more facet to this discussion that I think answers my dilemma (and yet another analogy).

We can use tools or make tools. We can use pre-made tools or our own-made tools. We can use modified pre-made tools also.

The way I try to go about my process for programming is to (if I am making my own tool) determine if there are tools already that meet my needs. If I need the tool to do more, I can customize it/tweak it/ pimp it.

Then you look at the designer of the tool, and you try to see if they made their tool in a way that makes it easily customizable, or whether the tool was created for THEIR needs.

The tools I would like to create, I would like to create them to be extensible and customizable. So I try to root it all in the basics. What basic features does a tool like this need? This is why I like the term "modular."

This approach is not only for others, but for me also, if I need to add more functionality to my tool that I may not have needed before,. Of course I would want the tool to be easy to use and modify also.

This is where the tool becomes a way of life. Perhaps this is the secret to design? Apple Inc, for example went for simplicity and ease of use, but still kept the tool powerful. Now they are almost a way of life for people. It became like a staple. One thing they lack is customization. This is where Android shines. A merger of the two would be pure gold (let's go Linux!!).

Who doesn't have a hammer somewhere in their house? Who doesn't have a stove? Bed?

Though there be countless types of beds and houses and such, they all have some basic functionality. I see a need for more modular design. Then we can say our tools have that mass appeal.

This thread has been fascinating to read, though I'll admit I glossed over the analogy acrobatics in the middle. I do think there is an even more fundamental facet than Tutorial Doctor suggests above to consider.

The fundamental question is simple: do you care about making things for other people, or do you only care about yourself?

The actual fundamental question is this: why is composability* so poor in our current languages/technologies?

This is something I've found myself wondering about more and more of late, perhaps a sign that I'm now really turning into a curmudgeonly old programmer. From operating systems to applications to programming languages, everything is so siloed and walled off that the pain of integration becomes, in many cases, the primary determinant of whether we seek out external solutions or build our own from scratch.

My day job is primarily as an iOS developer, and the popular dependency management options are things like CocoaPods or git submodules. Really? That's the best we can do in 2015? When I read about what was possible in the 1970s with Smalltalk and Squeak, where you could integrate components while your system was running, interactively explore their capabilities and then define the composed functionality you wished to expose, I almost want to quit the industry and go be an avant-garde sculptor or something.

In my experience, this is the real crux of the issue: NIHers/From-Scratch-ers look at the pain of integration and say, "Fuck it, I'll just build my own," while the others are willing to put up with potential and sometimes recurring pain to deliver results quicker.

What say you?

*By composability I mean the ability to compose new solutions from disparate, existing parts. It is functional programming jargon, to some extent, but really derived from mathematics, in which a function g(x) = f(x) op h(x) is defined as being composed of or over f() and h().