Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

> Except that in software 1000's of groups have already dug 1000's of canals and yet the next group that will build a canal will insist on doing it their way.

This is why a prudent developer/team would attempt to leverage frameworks/plugins/existing API's and libraries vs reinventing the wheel. Leveraging well-vetted and popular resources should cut development time considerably.



sort by: page size:

> Except that isn’t what software engineers largely do, we aren’t building the nth copy of the same building with a slightly different skin.

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.


> Building features in a cluttered codebase is like being asked to install plumbing in a hoarder's basement.

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.


> In the long run neither frameworks nor languages matter.

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.


> The top ten percent probably don't reinvent the wheel when they don't have to.

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.


> The average developer should just be using a framework.

Yes, and the non-average shouldn't.


> I wonder if we developers have a subconscious bias towards tougher way of building things instead of a much easier way.

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.


> They substantially lower the barrier to entry for creating product.

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.


> When everyone is committing to the same repo certain types of encapsulation and abstraction aren't always as critical as they're made out to be.

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.


> Code isn't fluid, it's calcified business process. That calcification requires regimented thought that developers can bring to the table.

Well said.


> Writing an API is less work than writing the devtools

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


>Aside from as a learning experience or display of prowess, what's the point of implementing A yourself?*

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.


> But the I in API stands for interface. A good interface can survive rewrites of what's underneath.

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.


> It’s easy to over-index on reuse as a primary goal of APIs (I believe taming complexity is a more important goal)

So true !


> Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework.

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.


> That said, I think this advice is particularly useful for people building libraries more so then people working on applications

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.


>Application developers should not have to become experts in the underpinnings of the library just to use it.

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 is developing so fast and the abstractions getting better

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.


> In any case, unless you're purposely writing completely nasty throwaway code, there is always some reusability, which typically makes starting from scratch in a new language a much weightier prospect than making some scalability enhancements to the existing base.

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.


> What I actually want is a ... and then letting the computer determine the most efficient way to develop those code paths and execute them

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

next

Legal | privacy