That’s exactly what most developers do.

There is far greater variation in boring bridges spanning small streams than most web applications and yet after more than 20 years we still can’t figure it out without some giant framework to do most of it for us.

Hah, yes! That's a great analogy. It doesn't mean you can't get the job done, it just slows you down every time you move around the code base.

While I agree with this statement, a real life project include several people, some new to the projects, some good, some not, some with experience and some young. It requires communication and sharing things.

And tooling helps a lot with that.

True, but they can invent the wheel because there isn't one, and they can do so in a way that others will find it useful as well. It is a different point than edw519 is making, but what he said made me think about where I disagreed and why. The purpose of code libraries, is to make everyone more efficient, by solving a problem so others don't have to. If that means a programmer can produce twice as much functionality within a given time frame, or is able to produce any functionality at all where he couldn't otherwise, there is still a net benefit for everyone. This should not be scoffed at; it is the reason why we are able to produce software as featureful and useful as we do. Imagine each of the XFCE, KDE, and GNOME teams having to rewrite X.org all over again, and how much less each of those desktops would have to offer right now if they did. I'm willing to trade useful functionality sooner for less machismo.

But libraries don't always achieve this, and the degree to which it doesn't determines which people will be motivated to create a replacement. If a framework solves a common problem, but does so in a painful, unwieldy, or hard to understand way, some hacker out there will probably think it a better, more efficient choice to just write and use a new solution. It might be a fork of or series of patches to the original framework, or it may be an entirely new codebase -- which of these routes to follow is a judgement call. Nevertheless, it requires what I think is an important distinction, which is the ability to not just understand what problem the framework solves, but how it solves that problem. And not understanding it just in following what each line of code does, but why what steps it takes work. At that point, you end up leveraging a framework far more that relying on it. If something tomorrow were to happen that required you leave it behind, it would be a pain in the ass, but not a brick wall.

There is also the question, more important that the above in my mind, of understanding if you actually have the problem the framework solves, or if you are attempting to shoe-horn. But I worry that might be a bit off-topic of this particular thread, and would probably warrant another 3-4 paragraphs of musing.

Yes, and the non-average shouldn't.

That and the fact you we don't know everything that's possible and stick to what we know.

But, there is another side of the story: reusability is hard, plus similarity and equality are very different things. Generalizing a problem can be more or less productive depending of your situation. Also learning how to use something and bend it to your needs can be an mistake too on the long run.

Mix complexity, money, human factors in that and you get the average IT project.

Which is still awesome if you ask me. Current softwares have many warts, but they are so freaking amazing.

It goes further than this: a good framework can lower the barrier to writing maintainable, modular code. Sometimes people just need a nudge to follow good practices.

Until you want to refactor or reuse. We develop a lot of in-house tools for our rather esoteric systems and systems analysis. We start by writing specific solutions, then refactor as we find common elements across tools. Now we have several libraries that can be used by anyone to develop custom solutions to problems because we've factored out common elements into those libraries.

Treating encapsulation and abstraction like they're unimportant would've resulted in a lot of extra work over the years.

Well said.

aka How to tell that you don't design APIs without telling that you don't design APIs.

Because for people working in those kinds of problems we're talking about (we started from Valve and games IIRC, but it could also be Google, Facebook engineers etc) you don't just download some off the shelf API.

You'll need to create something of your own to:

- have the whole IP

- mold it specifically to the domain logic you need

- take control of it's memory and performance characteristics based on your constraints

- implement it in the language your company uses, for which no ready made A* (or some other algorithm) is available

- you'll need to make it talk to different infrastructure, libs etc

- you might be the one writing the library API yourself

As I said, this is not about what a CRUD programmer will need. But as you can see everyday in HN, people write these and other algorithms all the time in their jobs doing more serious engineering.

Absolutely!

But a good interface is also a really difficult thing to engineer, in part because it seems like a relatively easy thing. The gotchas don't become apparent until long after you ship.

Sometimes I wonder if some of this is just cost-cutting. A difficult task is an expensive task. Other times, I wonder if it's because API design is an actual specialty, and there are too many devs doing it who don't have the chops for it.

So true !

This is simply false.

On the other hand, every sufficiently complex framework-dependant application is way too complex for what it does, and would be a lot simpler if it was not using said framework.

> My last and--to me the most significant--observation is this: You want to pay the majority of your attention to the code that has the greatest impact on your desired outcomes.

One of your greatest desires should be to have strong propietry technology that you control. Otherwise you are not different from anyone, and anyone can duplicate your work in two months by just using the same framework.

This is a good point that I hadn't really thought about previously. I agree with your thoughts much more when I consider the different needs between libraries and applications.

I understand that that is the final goal. But as we introduce new technologies it takes a time and more powerful machines until they can be simplified.

There is a lot of people asking for easy ways to build systems for millions or billions of users. We will get there but we are still not there. It is amazing that it is already so much simpler and cheap than 10 years ago.

If a product with similar features is easier to use makes sense to choose it. But demand simple solutions to complex problems looks like out of place.

Software won't eat software because this isn't true, yet.

IMO, the last 10 years have been an explosion of new frameworks and patterns that are overly-complicated and bloated. Because of this, there isn't an easy cohesion between off-the-shelf solutions.

Think of how eye-opening UNIX was when it first came on the seen and the ability to pipe together commands to solve new problems. It was eye-opening. But, think of how hard that would have been if each tool read ASCII different, or piped text differently. Imagine if grep and awk where combined into one tool with a complicated set of switches.

I think eventually, working with off-the-shelf software to build solutions to tough problems will be as easy as gluing together 3-5 UNIX commands in a bash script to process some text files. But we aren't there yet.

It's not really from scratch. If you've figured out the correct structure and interfaces to solve your problem you can reuse all that when porting to a different language, and that's the hard part of development.

Give us something actionable and not handwavy dreaming and you might get it.