Live data from Hacker News

Finish your stuff

250bpm.com

21–30 of 104 posts

Re: Finish your stuff

#21

There is a whole class of rhetorically attractive analogies comparing programming to the building of physical things like furniture, bridges, and buildings. They usually overlook that software requirements vary greatly and can be quite complex, while the physical requirements of a chair are not going to vary much across chair designs. Modification of software requires no physical resources and can be executed at scal…

I think the article does address that to some degree. My interpretation is that if your requirements change so much and are so complex that you are not able to complete the solutions, then you should step back from coding and work more on the requirements.

Of course that also means slowing down, and obviously that won't do in silicon valley. Gotta go fast, even if you are running around like headless chicken.

Re: Finish your stuff

#22

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…

It's finished when there's nothing left to remove.

Re: Finish your stuff

#23

Great software projects are never finished; instead they always evolve and improved similarly to living organisms and unsimilar to material things. I completely disagree with your analogy to a carpenter who builds a chair, this metaphor is wrong and responsible for a lot of misunderstandings when it comes to software development.

Many great software projects are never finished. All un-great project remain unfinished.

Re: Finish your stuff

#24

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…

It's finished when there's nothing left to remove.

As long as you don't remove things from the problem in the name of removing them from the solution.

Or, to be less terse, don't say "Well, you shouldn't need to solve that problem!" or "You're holding it wrong!" Reality doesn't give you neat problems which map cleanly to the simple solution, and adding complexity is the only way to solve the problem, as opposed to a dishonestly reduced form of the problem.

Re: Finish your stuff

#25

There is a whole class of rhetorically attractive analogies comparing programming to the building of physical things like furniture, bridges, and buildings. They usually overlook that software requirements vary greatly and can be quite complex, while the physical requirements of a chair are not going to vary much across chair designs. Modification of software requires no physical resources and can be executed at scal…

> They usually overlook that software requirements vary greatly and can be quite complex, while the physical requirements of a chair are not going to vary much across chair designs.

I feel as though that's somewhat addressed in the essay:

  Yes, I hear you claiming that your project is special and
  cannot be made functionally complete because, you know,
  circumstances X, Y and Z.

  And here's the trick: If it can't be made functionally
  complete it's too big. You've tried to bite off a piece
  that's bigger than you can swallow. Just get back to the
  drawing board and split off a piece that can be made
  functionally complete. And that's the component you want
  to implement.
Software engineering is an offshoot of systems engineering, which is often described as "managing complexity". I don't think it's at all unreasonable for people to look at the methodologies actual systems engineers use and learn from them. One of those things is decomposition of tasks, what this article is about. If you're making a message queue system, divide it into subsystems that are each more feasible. Your over-the-wire data format protocol is one thing (asn.1, protobufs, etc.), your concurrency library and patterns in your systems are another (go's channels, erlang's processes, libmill from the article), your database is another. Once you have your system decomposed in this fashion you can do each part, and actually finish them, and assemble your complete system by combining them.

Once they're small enough the Unix philosophy applies. Write components that do one thing and do it well, and design them in a way to communicate with each other.

Re: Finish your stuff

#26
post #21

There is a whole class of rhetorically attractive analogies comparing programming to the building of physical things like furniture, bridges, and buildings. They usually overlook that software requirements vary greatly and can be quite complex, while the physical requirements of a chair are not going to vary much across chair designs. Modification of software requires no physical resources and can be executed at scal…

I think the article does address that to some degree. My interpretation is that if your requirements change so much and are so complex that you are not able to complete the solutions, then you should step back from coding and work more on the requirements. Of course that also means slowing down, and obviously that won't do in silicon valley. Gotta go fast, even if you are running around like headless chicken.

If you're designing for yourself, sure, work on the requirements.

If you're designing for the marketplace, the market decides the requirements, and expecting everyone to fall in line behind one thing is a mugg's game.

Re: Finish your stuff

#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 your app isnt growing and changing, to users it way well look dead: "It's abandonware".

Re: Finish your stuff

#28
> Imagine the carpenters were like programmers. You bought a chair. You bought it because you've inspected it and found out that it fulfills all your needs.

Then, every other day, the carpenter turns up at work and tries to improve how they make chairs!

Why can't they just stop changing how chairs are made? I like my chair, but I go back to the store after a few years and they're all different! Carpenters, finish your chairs. Those ideas you have? Stop having them. I like chairs how they are now.

Re: Finish your stuff

#29

> Imagine the carpenters were like programmers. You bought a chair. You bought it because you've inspected it and found out that it fulfills all your needs. Then, every other day, the carpenter turns up at work and tries to improve how they make chairs! Why can't they just stop changing how chairs are made? I like my chair, but I go back to the store after a few years and they're all different! Carpenters, finish you…

That is how market works, people not satisfied with sitting experience and constantly trying to improve on that, yet QWERTY layout is still in use by 99.9%, it is enough to satisfy typing needs and good enough experience so nothing changes for ages.

Re: Finish your stuff

#30
I don't think the chair example is appropriate, because I think there are different, more comfortable chairs today than let's say a 100 years ago. So the "chairmans" are continuously improving the chairs, just not the one you bought.
Post reply on HN