Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Finish your stuff

250bpm.com

Post reply on HN
Print view View original

51–60 of 104 posts

Re: Finish your stuff

#51

Post by a_t48 »

Jtsummers wrote: post #40
sly010 wrote: post #38

Earlier quoted context omitted.

But then you didn't solve the problem. You solved pieces of the problem.

That's a part of software engineering though. Once you reach a certain scale, you have to decompose your problems into subproblems. You solve those and assemble them into the final system. The people making AMQP (following the original author's example and line of reasoning) were solving too many problems: they had a message queue, they had a wire protocol, they had service discovery, etc. This is all fine . The auth…

> We don't reinvent TCP every time we want a new network protocol

Hey man, speak for yourself. Reliable UDP is where its at.

Re: Finish your stuff

#52

Post by Jtsummers »

alkonaut wrote: post #47

software is never complete. It might be usable (in the world outside personal projects perhaps "shippable") but never complete. I think the point the author is making is to not start projects that aren't likely to have a minimum viable product that is usable and achievable within reasonable time. I'm not so sure. It's more fun to write the skeleton of a compiler and abandon, than it is to write something minimal some…

The point of the author is to define your targets. When you're building a compiler if you're also building a parsing engine then maybe the parsing engine should be its own project, with the compiler a separate project that uses the engine. When you build a web app you don't closely tie in the web server code, you use an existing or build a new web server. When building a web server you don't build the TCP stack with it. You make the TCP stack and then have the web server use it.

Complex systems are constructed from smaller, less complex subsystems. Complete them, let them standalone and build out our final systems from them. We generally don't rewrite tools like grep because it exists and it works well, we may port it to new platforms. And we don't change the effects of the -R flag out from under the users (clients), it is what it is. The interface is, essentially, completed.

If you're leaving incomplete hobby projects in your wake (all of mine are), that's not what he's talking about.

His specific experience was going from AMQP (large, complex specification) to ZMQ (smaller, focused on the essentials and let complexity be built on top) to nanomsg and libmill (even smaller, more focused). So in theory his nanomsg and libmill could be considered complete, as we'd consider TCP "complete", today (from a client perspective at least). And we can work our way back up plugging it into systems to recreate the capabilities of ZMQ, which can be plugged into systems recreating the capabilities of AMQP. Which can then be used to solve our business problems.

Re: Finish your stuff

#53

Post by elihu »

I don't agree. The goal of software isn't usually to discover some perfect abstraction with nothing left to add and nothing to take away, the goal is usually to solve some practical real-world problem. If your software satisfies the requirements without taking too much time or effort to create, then it's a success.

If a project is going to be used by a lot of people or become some kind of industry standard, then it makes sense to spend some time up-front and figure out a clean interface and a well-defined feature set so you don't have to make non-backwards-compatible changes. It also makes sense to look at the feature set and figure out if you have the time and ability to complete those features, whether they're important enough to justify the effort, and whether there's an easier option that satisfies the requirement without having to boil the ocean. All this should be driven by the project goals, though, not some abstract ideal that all programs should be complete.

Some of the most useful software is going to be forever incomplete. Web browsers, CAD packages, operating systems, etc... I'm glad there are people working on software like that.

Re: Finish your stuff

#54

Post by eurticket »

projectramo wrote: post #4

What would that look like? Consider an example: You have made a little web app that beeps at certain times of the day to remind me to do something. Is it complete? Oh, you want a calendar integration. That makes sense. You add it. Is it complete? Oh, you say you want to release mobile versions? Okay, now is it complete? Sorry, but the iOS version needs to be updated to remain compatible. Now is it complete? There is…

I think we all can imagine it means you get the app running in the first place, it's in a stable state, ready for modifications and improvements; done in this circumstance should mean, the-first finalized version after the rough drafts-done.

Re: Finish your stuff

#55

Post by Jtsummers »

a_t48 wrote: post #51
Jtsummers wrote: post #40

Earlier quoted context omitted.

That's a part of software engineering though. Once you reach a certain scale, you have to decompose your problems into subproblems. You solve those and assemble them into the final system. The people making AMQP (following the original author's example and line of reasoning) were solving too many problems: they had a message queue, they had a wire protocol, they had service discovery, etc. This is all fine . The auth…

> We don't reinvent TCP every time we want a new network protocol Hey man, speak for yourself. Reliable UDP is where its at.

I had "(typically)" in there originally. Should've left it, but it's complete so I won't change it now.

Re: Finish your stuff

#56

Post by [deleted] »

1001101 wrote: post #17

Somebody has given up a significant amount of their time to give you something that's free as in beer and speech. You get at least what you pay for, don't ask for your money back.

[deleted]

Re: Finish your stuff

#57

Post by Steeeve »

I find this funny coming from the originator of ZeroMQ. When I firt tried out ZMQ it took me all of 12 seconds to figure out that if you didn't pass exactly the message that it was expecting, it crashed the server.

That problem along with I'm sure hundreds of others were fixed along the way.

You don't achieve perfection in software development. Ever. Even when developing something for yourself where you define the scope and you leverage it for a menial task. There's always better. There's always more robust. There's always something else you can do.

That's the draw to software development for many of us. There is a constant challenge awaiting our brain. You can consistently push yourself in a new direction that you care about.

The downside is that feeling of a completed accomplishment really is just an arbitrary release ceremony. What software developers need to get good at is letting go and moving on.

Re: Finish your stuff

#59

Post by Jtsummers »

elihu wrote: post #53

I don't agree. The goal of software isn't usually to discover some perfect abstraction with nothing left to add and nothing to take away, the goal is usually to solve some practical real-world problem. If your software satisfies the requirements without taking too much time or effort to create, then it's a success. If a project is going to be used by a lot of people or become some kind of industry standard, then it m…

The author's point is not that there shouldn't be new systems or that no systems should ever change. He's not arguing for a perfect abstraction, either.

Following his development path (AMQP->ZeroMQ->nanomsg + libmill + others) his interest was in decomposing the larger system (AMQP which included message queues, databases for storing messages, wire protocols, etc.) into its smaller parts so that you could build back up to it in a better way. It happens that when you get to those lower levels, you can call them done.

If you're building a web browser, what's the proper scope for your project? Should it actually consist of all of these things in one project: tcp stack, http client, javascript interpreter, html parser and renderer, keyboard drivers, mouse drivers, touch screen drivers, etc.?

No. You build on the existing OS for the drivers. You build on the OS for the TCP stack. You may build an HTTP client, but odds are you can reuse an existing one, or the one you make could be partitioned off into a separate, and hopefully reusable, library. Your javascript interpreter can also be its own project/library. And most of that already exists, so you can focus on HTML parsing and rendering and glue in the other components. Your HTML parser doesn't need to know how to send an HTTP request, your renderer doesn't need to know it either. Only your browser needs to connect the HTML renderer and the HTTP client.

Re: Finish your stuff

#60

Post by aeorgnoieang »

icebraining wrote: post #37
kenshi wrote: post #27

> Please join me in my effort and do finish your projects. Your users will love you for that. Will they? If your users are programmers, they might love you for that. For pretty much all other users, they will want more. "It would be great if your app did...". I would argue that users now expect software to change and add more features. And why wouldnt they, when pretty much all software they use is doing this? If you…

That's actually not my experience; I see people using "old" software all the time, and rarely looking for newer alternatives even if they feel that some things could be added or improved. As just an example, my mother still uses ATnotes - last released in 2005. And I think the limited data we have shows that, like the number of people who upgraded their browsers before it was automatic.

And my experience is that there are many many combinations of some amount of both. I find a combination of both even with myself and sometimes even for a single piece of software! "I wish they'd add Markdown support!" "I wish they hadn't changed the UI!"
Post reply on HN