14 ms·

Finish your stuff

406 points by cjg 11y ago

sova 11y ago
Some very practical, down-to-earth, solid advice. Lines I found insightful: "... make it functionally complete in the first place. ... 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." ^_^ I really like the idea of splitting a project into phases. You might have Three phases, each one building on the last, but the very first complete phase should be a complete and usable thing in itself. First the skateboard, then the scooter, then the bike, the motorcycle, and finally the car.
- soft_dev_person 11y ago
  If I ever buy a car with skateboard as a chassis, I'll be very disappointed! Sorry, just had to =)
  - bbcbasic 11y ago
    Probably it should be build the tyre first. This is a functionally complete thing that can, along with many other functionally complete things be composed into the car.
    - kbutler 11y ago
      Car built with scooter tires... Scooter built with car tires... Just not seeing it. When Java was first becoming popular, I recall emphasizing how important it was to use the standard, well-documented, well-tested java.lang.String, rather than a custom String class as had been done in C++. Application domain experts started asking about strings that didn't fit in RAM (documents). A great, tested component in one domain may require a significant redesign in a domain with other requirements.
      - sova 11y ago
        Coding is a conceptual art-form, it's not about building a car with scooter tires, it's about upgrading vehicles to get the end result in a workable fashion. Try using spark plugs and pistons to get somewhere!
      - bbcbasic 11y ago
        Car built with car tyres. Analogy wears thing because a tyre is a standard off the shelf thing. In software everything that is interesting (and requires employees) is custom to some degree. So it is like a tyre for a rover on the moon. However no need to get that to also work for a scooter on pluto! Unless the sales guy has already promised it!
    - sova 11y ago
      step 1 "invent the wheel"
    - lmm 11y ago
      No, you miss so much when you try to make a component you think will be useful. The first piece must be something that makes someone's life a little bit easier - that's the only way to be sure you're making something actually useful.
- pdpi 11y ago
  > First the skateboard, then the scooter, then the bike, the motorcycle, and finally the car. I've always found this metaphor incredibly amusing, because, to me, it actually highlights the _problems_, rather than advantages, of the iterative approach. At every step of the process, you're not only increasing complexity, you're also pivoting your product to the point where: 1. your previous clients are unlikely to still be well served by the new product, and are likely to churn as a result 2. the engineering challenges are different enough that most of the components aren't really reusable, and trying to shoehorn one stage into becoming the next will give you a sub-par product.
  - sova 11y ago
    It's not about incremental development, it's about passing the baton. The spirit is motion/movement/transport, and the corresponding vehicle should be a natural expression of that with your available tools. Who said that the goal should be product-oriented? If I want to reach Alaska I will gladly take whatever transportation suits me best at the time. If I were insistent that my tank was clearly the most capable vehicle, although I would eventually get there, it would not be as enjoyable, imho.
- rumcajz 11y ago
  Aside of it being convenient for users, keeping the components small is good for the developer as it tends to tame the complexity to the acceptable level.
shabbyrobe 11y ago
What does this mean for the future of nanomsg's development?
- rumcajz 11y ago
  The project was take over by Garrett D'Amore so it's up to him to decide on its future.
  - shabbyrobe 11y ago
    Thanks for the reply. Are you still involved in any capacity or have you decided to move on from the project entirely?
melling 11y ago
"Real artists ship" "if you are not embarrassed by the first version of your product, you've launched too late" https://en.m.wikipedia.org/wiki/Release_early,_release_often https://en.m.wikipedia.org/wiki/Release_early,_release_often I'm sure there are many others, but these ones keep me shipping.
- georgerobinson 11y ago
  If you're embarrassed by the first version of your product (i.e. suppose it's buggy, or is lacking in it's UI) then it's probably not ready to ship? There is nothing worse than shipping a half-baked product.
  - keyle 11y ago
    I think you're both right. And knowing the right balance is the key.
    - melling 11y ago
      Reid Hoffman: https://pbs.twimg.com/media/Bldr6K1IEAAzeSl.jpg:large https://pbs.twimg.com/media/Bldr6K1IEAAzeSl.jpg:large
      - emodendroket 11y ago
        Thanks. I had trouble reading it in text form, but now that it's an image that includes a guy's head I get the point.
        melling 11y ago
        I thought there was some confusion about who the credit for the quote went to. People weren't referring to Reid by name. The link was simply the first Google result that I clicked. Random.
      - VSpike 11y ago
        In the case of LinkedIn, the world might have been a better place if they'd never shipped at all.
Kenji 11y ago
Slightly OT, but Except for some basic UNIX tools, like grep or make Is make a basic tool? I'm often surprised when I find out new features of make that I was unaware of. I feel like it's bigger than it appears to be.
- emmelaich 11y ago
  I consider make a basic tool. So much of programming and administration is about managing dependencies, and make is the default tool. Such a pity it has a shitty syntax.
  - berntb 11y ago
    There is no reason for Make to have a "shitty syntax", since it would be easy to have an alternative syntax -- which make recognized and handled differently. (So make would be backwards compatible.) With the way software updates percolates out in distros, a new make format could be supported in five years on most every server and desktop everywhere. I think the reason this haven't happened after decades is because make works. If you want to prove me wrong, read previous paragraphs. If you succeed, I'll buy you a beer. Hell, we should all buy you a beer if you improve our life quality. :-) (Yeah, I'm hellbanned.)
- sitkack 11y ago
  Basic doesn't necessarily mean simple. In this context, I think it refers to a low level building block.
- lmz 11y ago
  Those features are probably extensions. The POSIX specification for make is quite simple: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ma...
amelius 11y ago
> You bought a damned chair and you want it to remain a chair, not to find out that it's some kind of protean piece of furniture that's a chair today and partly a table tomorrow and, who knows, maybe you'll be able to humidify your cigars in it next week. This is exactly my problem with web-services (and software that auto-updates itself).
- HappyTypist 11y ago
  Every software is like this to some extent. The more external stuff they link, the more affected. Even if something doesn't auto update, eventually you'll have to update to the latest version because certain functionality will no longer work the way it should. Sure, you can fork it, but many software projects take more than one person to maintain.
- emodendroket 11y ago
  I wish more software updated itself. I don't want to navigate to the download page and run the installer every time it updates. That's busywork.
  - dublinben 11y ago
    This is already a solved problem with package managers. You shouldn't ever have to "run the installer" each time you need to update a program.
    - orkoden 11y ago
      The software in my package managers' sources is outdated.
onion2k 11y ago
There's a great list of project management advice by Jerry Madden of NASA that gets posted here occasionally[1]. One of the points is; "Rule #30: It is mainly the incompetent that don't like to show off their work." Madden's remark is based on the specific environment he was involved in (NASA engineering); if you're surrounded by people who are good at their jobs and who know how to criticise constructively then there aren't many reasons to hide what you're doing other than it being a bit rubbish. I don't entirely agree with the idea that people who don't show things off are necessarily incompetent, especially if showing off your work means putting it under general public scrutiny (who can be very nasty), but there's a huge amount of value to be gained in getting feedback from your peers as early as possible. [1] http://www.nasa.gov/pdf/293253main_62682main_jerry_madden_forum7.pdf http://www.nasa.gov/pdf/293253main_62682main_jerry_madden_fo... (Non-PDF version: http://www.altisinc.com/resources/rules/ http://www.altisinc.com/resources/rules/ )
- mironathetin 11y ago
  There are other important reasons not to show things before they are done: one is the impatient group member who rather refocuses a development than to wait until it converges to something usable. It takes a lot of experience to make a realistic guess, how long software projects take. It also takes a lot of experience to put progress reports in a way that it always looks like great things are happening in order to avoid the refocus discussion. The all important point is a constructive team that knows their job. But especially in space project related development, you may be surprised to find managers who don't know much about software.
  - wiz21c 11y ago
    I'd say it is a better idea to show something finished (or if it's too big, a part of it that it finished). Because if it's not finished, those who look at it will have hard time to understand where you are, where you can go and thus they'll have hard time making a good review of it, or worse, they'll associate the unfinished stuff to your incompetence, lack of vision, lack of will, whatever.
- objectified 11y ago
mironathetin 11y ago
"Lately, after 30 years in the programming business, I've finally managed to cut down my projects to a reasonable size." ... long before those thirty years, someone who thinks he is a great manager may take over the steering wheel (he or she). And things are ready to start from the beginning. Im my group, we have another flavour of not finishing things: managing by whatever is in front of the managers mind and declare it highest priority. This is the best way to work hard all the time and get nothing done at all. Well, we all read peopleware a long time ago, all except of the managers. Anybody here, who has a good idea how to handle these traps?
- otherusername2 11y ago
  > managing by whatever is in front of the managers mind and declare it highest priority Bane of my existence for the longest time. Eventually I learned to just ignore those managers. They're too chaotic to remember whatever I was supposed to work on for them anyway.
  - mironathetin 11y ago
    Ignoring seems to me like the secret weapon of the powerless. I like to confront, discuss and get things improved. But it is so hard to get incompetent managers up to speed, if they lack years of experience.
    - otherusername2 11y ago
      > the secret weapon of the powerless It is. I've had a few managers where everything we all tried to change change were fruitless. The only solution was to either antagonize until things got out of hand, or to ignore. > I like to confront, discuss and get things improved That's a good initial starting point. But I've also learned that there comes a time when expending any more of my own energy fighting such people is no longer worth it. > incompetent managers In my cases, it wasn't incompetence but rather character. You can have rational discourse with incompetent people. You can show them why they're wrong. You can't have a reasonable discussion with someone who's own mind jumps from high-priority to high-priority, wanting everything yesteryear but isn't willing to put in the actual resources to get things done. I've dealt with too many managers like that to expend much energy on it anymore. Mind you, ignoring them should be a last resort, but given enough experience with such managers, you learn to quickly know when you're dealing with one. I'd much rather spend my time making customers happy.
z3t4 11y ago
If you think "giving up" on a project is easy. Try "giving up" on your "dreams", those project you work on every day, even though you know you wont make it.
gedrap 11y ago
In my own experience, I found the following 2 things being the most important: 1) Keep it fun. Sometimes you start working on something and a week later you realize it's not as great as you expected it to be. Maybe you are working on some game and you can see it won't be as fun to play as you thought, etc. It's fine, it's ok to stop working on it. Forcing yourself to work on it won't produce any good. 2) Start with well defined, small goals. Define v1.0 which would contain only the most critical features, ship it (even if it means simply tagging on git). There's something hugely motivating about completing things, no matter how simple they are. EDIT. One more thing I'd add, when working on a side project, don't start thinking about how everyone will be using, how many thousands of github stars it will have, whatever. It doesn't even have to be actually useful, as long as you have good time and learn something on the way. I've worked on a few projects that I'd say are totally useless (such as https://github.com/GedRap/xs-vm https://github.com/GedRap/xs-vm ) but at the same time I see them as successful because a) had great time b) learned something new, even if it's some small details about a library or a language.
- TheOtherHobbes 11y ago
  I've found: 1) Usually getting something finished is a boring slog. You get the (you think...) brilliant idea phase when you're all fired up, then you get "this is really boring" phase when you're working your way through a thicket of problems, squashing bugs, finding new bugs, thinking you should refactor (you shouldn't, usually) and completion seems like an ever-receding goal. 2) Break big goals into smaller goals. Repeat recursively until done. Then do it some more, because you missed a few things. Sweat the small stuff, because when you glue it all back together and you've worked through phase 1 properly, the big stuff just works. (Or near offer, anyway.) Keep the cognitive load low: small microprojects and problems, one at a time. It's not unusual to have problems with phase 1. But it's also the difference between being a professional and being a hobbyist. If you just keep starting new projects when you hit phase 1, you don't ship.
  - gedrap 11y ago
    Valid point, I totally see what you mean. >>> You get the (you think...) brilliant idea phase when you're all fired up, then you get "this is really boring" phase. In my experience, there are 2 kinds of 'really boring' phase. One kind, as you mention it, is the less exciting part of the work, be it writing docs, or some edge case bugs, etc. The other kind is when you discover that you largely underestimated the complexity, or saw some major flaws in the initial idea. Like I've mentioned in my previous comment, maybe you start working on a game and find out some major flaws in the gameplay and can't see it being a fun game to play anymore. While it's not always obvious which case you are facing, in the later case, in my opinion, it's fine to halt the project. If you don't believe in it, nothing good will come out of it. >>> It's not unusual to have problems with phase 1. But it's also the difference between being a professional and being a hobbyist. I guess it depends on what's the purpose of the side projects. If it's something you try to make a business of (passive income kind of thing), then yeah you totally should get a bit of extra will power to get it shipped. But if it's something that is done just for fun, then I wouldn't sweat it that much.
wainstead 11y ago
I thought the Unix philosophy embraced the idea of "small tools that do one thing really well." > Please join me in my effort and do finish your projects. Hear, hear. A friend and I hosted a "Finish it! Weekend" once (as opposed to a "Startup Weekend"). The idea was to get people together for one weekend and finish that last 10% or whatever of a project. Sadly we were the only two to show up. (And we both finished our projects, which suggests this might be a good kind of hackathon to host every six months or so).
- voltagex_ 11y ago
  Would you consider hosting that with remote participants? I'd love to do a *thon like that.
  - rafaqueque 11y ago
    That's a very good idea. I'm up for that, remotely.
  - wainstead 11y ago
    Sure! What kind of "venue" would you suggest? (Lord knows I have plenty of unfinished projects myself!)
    - S4M 11y ago
      A dedicated chan on IRC maybe? EDIT: Also: I might take part if the "Finish it" weekend takes place, provided my wife takes care of the kids long enough.
    - voltagex_ 11y ago
      If you wanted to make this big you could get a whole lot of hackerspaces to participate. I'd suggest IRC for now.
- prawn 11y ago
  Nice idea. Call it a "FinishUp Weekend" as opposed to a "StartUp Weekend"?
qznc 11y ago
The point of the article is not "Finish your stuff", but "Tackle smaller problems".
- cafebeen 11y ago
  That sounds more in line with the unix philosophy!
pfortuny 11y ago
Oh, come on: software is usually much more than a table or a chair. It grows, it needs care, it is more like a plant than something static. What does it even mean to "finish" a program like 'ls' given the increasing complexity of filesystems with time?
- Loque 11y ago
  I caught myself thinking the same thing, however if you compare software to a physical product the importance of the analogy remains intact. It may not apply to you however, I have been lucky enough to be surrounded by some very well disciplined developers who make a point of finishing a lot of what they start to varying degrees of success.
- vezzy-fnord 11y ago
  The semantics of POSIX dirents haven't really changed, and any file system complexity is abstracted by the kernel's VFS subsystem to provide generic data in all cases. So, yes, it is possible for something like 'ls' to be finished, or at least for really long times.
  - pfortuny 11y ago
    Ok, yes, my example was not the best one. But at the same time, consider things like UTF-8, localization, etc. They appear at the least expected moment and someone has to do something unless the tool becomes useless. I understand you get the idea, though.
jsingleton 11y ago
The Zero MQ guys seem to have some pretty good wisdom to impart. Pieter Hintjens has a free book at http://cultureandempire.com http://cultureandempire.com which is worth a read.
- brudgers 11y ago
  The ØMQGuide itself is pretty awesome, too. http://zguide.zeromq.org/page:all http://zguide.zeromq.org/page:all
- vidarh 11y ago
  The iMatix guys have been amongst my heroes since they released Libero (state machine code generator) and built Xitami on it (both mentioned by Hintjens as "finished" projects in a comment to the linked article) back in the 90's...
  - vanessa98 11y ago
    Why is there so much dysfunction around everything they do?
    - vidarh 11y ago
      Is there? Care to expand?
jblok 11y ago
"Lately, after 30 years in the programming business, I've finally managed to cut down my projects to a reasonable size." After 30 years of programming, you'd better be a pretty decent programmer. And maybe that's why their projects take less time to complete.
- vidarh 11y ago
  If you look at his progression, a lot of it is also about shaving down the size and complexity. E.g. the AMQP -> 0mq -> nanomsg chain which is a journey of cutting complexity.
linux_devil 11y ago
Very good read , particularly comparison of chair with product in first few lines was opener .
euphemize 11y ago
I like this idea, but I'm not sure it's realistic. Constraints change all the time, just like your users' needs. In principle this works, but I'm not convinced that everything should aim to be finished.
rdtsc 11y ago
Is nanomsg finished? I found its Windows support rather broken -- failing test cases. Strange lockups. https://github.com/nanomsg/nanomsg/issues https://github.com/nanomsg/nanomsg/issues I do not see Martin working much on those these days. Does anyone know how untangle those state machines besides him.
- shepardrtc 11y ago
  Martin has passed the reins on to Garrett D'Amore, but I would say the majority of the project is finished.
- vidarh 11y ago
  See his comment in the comments on what he thinks about how to decompose nanomsg, it's quite interesting.
ams6110 11y ago
Just an aside on the carpenter metaphor, there's sort of a running joke that a carpenter's house is never finished. It's not just the software profession that has this problem.
- innguest 11y ago
  But as the carpenter goes on doing his stuff, the things he did stay put. They do not suddenly become incompatible with each other, or need to be maintained daily. Carpentry is orders of magnitude less brittle. It doesn't even compare. Programming is more like policy writing. Definitely not like carpentry.
emodendroket 11y ago
Now what if your home regularly changed in such a way that your old chairs didn't sit upright anymore? There are limits to the carpentry analogy.
- rumcajz 11y ago
  If your chair covers the area of Los Angeles, it'll sure have problems with changing landscape. If it's a regular-sized chair, less so.
  - emodendroket 11y ago
    Yes, but now we've clearly abandoned the familiarity of the analogy, making it less clear how much value the analogy has in illuminating what we're trying to say.
- artmageddon 11y ago
  Right, and even the use cases for software can change in such a way that it can influence the entire architecture. "We want to design a simple rocking chair for a sweet elderly couple." becomes "We need to make enhancements to this chair to equip it with an ejection seat suitable for a fighter pilot in a jet. No, you can't start over either, there isn't enough in the budget for that."
- vidarh 11y ago
  In which case perhaps the reasonable solution is for you to get a different type of chair, rather than trying to modify your old chairs to fit the changing requirements.
netcraft 11y ago
Am I the only one that really hates the carpenter analogy? As someone who does woodworking on the side of my programming, there's a million reasons why it's a terrible way to think about software development. The chair doesn't have supported platforms, new security issues, or the need to be updated so that people keep buying the same chair. Someone else isn't going to have to come along later to maintain the chair and have to be knowledgeable about the specific tools that the chair was built with.
- emodendroket 11y ago
  Don't forget that a programmer's work is not really like making three of the same chair either. Maybe if every single thing the carpenter made was a highly customized bespoke piece.
- diminish 11y ago
  Carpenter analogy is as bad as the "book author" analogy. You write a book and let it go. Nothing to support, all updates are to be paid by customers in a new release.
  - clord 11y ago
    "Book author" is at least closer to the truth. There are editions and old copies floating out there, it's hard to estimate completion dates, and authors have many of the same copyright problems. The difference is that software must live in a dynamic and shifting 'house' where everything gets rearranged by vendors, probed for weaknesses by attackers, and new features are constantly demanded by the users. Solutions to all of this are tacked on as an endless stream of appendices. Throw in patents for extra insanity. Both analogies strain to fit this reality. Edit: That brings me back to the article. "Finishing software" just means we should act more like authors. Very hard to achieve when you think of the differences above.
    - stephengillie 11y ago
      Some books do have versions (textbooks et al), some books are out-of-date as soon as they are published (statistics, science). Many would benefit from a reduction in lines and becoming more concise. Some are a jumbled mess that's basically useless, but nobody wants to update them.
kefka 11y ago
> Imagine the carpenters were like programmers. So, they do the work for free, and updates as long as people keep using it? Terrible analogy.
jdimov9 11y ago
This is absurd. A finished project is a dead project. If it isn't improving, it's dying. Never finish your projects (unless you're just doing homework). Software is a system. Systems of any non-trivial complexity are living things that must adapt and evolve. Constantly. (Also, there is absolutely nothing wrong with abandoning a project. Gain as much as you can from your experience and quickly move on to something better / more meaningful.)
- firethief 11y ago
  Is TeX dead?
  - jdimov9 11y ago
    You had to fish hard for this example, didn't you? Sometimes, genius strikes and you get something so precisely thought out and so well executed that it lasts for generations. Still, I'd have to answer your question in the affirmative. The original TeX is quite dead indeed. It (and the ecosystem around it) have evolved significantly over the years and continue to evolve as we speak, so it is far from finished.
  - lmm 11y ago
    Given the state of its unicode support, yes.
- vidarh 11y ago
  By that token a substantial proportion of the tools I rely on on a daily basis are dead. (not least if you consider the actual contents of the linked article, which makes it clear that by "finish" he means to make it functionally complete, not to stop fixing bugs or e.g. ensuring it still compiles)
- segmondy 11y ago
  Your comment is absurd. "A finished project is a dead project?"
  - jdimov9 11y ago
rlpb 11y ago
I find it irritating when people look at some of my projects on Github and consider then "abandoned" because they haven't had any commits in a year or two. They're not abandoned: they're finished. They do what they're designed to do, and I use them regularly. Outstanding issues may exist for feature requests that I don't need, or for minor bugs that won't occur in anything but obscure edge cases that don't apply to the primary use case. I welcome high quality patches but otherwise have no interest in pursuing them.
- enraged_camel 11y ago
  If it's anything you expect other people to use, then I'd consider anything that hasn't been updated in the past year "abandoned", yeah. If it's your personal projects though, I don't make that assumption.
  - vidarh 11y ago
    I have several projects that haven't been updated in more than a year which are still maintained in the sense that if there are bugs, I fix them. They are rarely touched for a simple reason: They do what they're meant to, and they still work. I wish more software took that approach. Far too often software quality drops after a while as developers keep piling on the features.
  - nathan_long 11y ago
    Abandoned or stable? If it has no dependencies and a small feature set, it may just be done. "Stable" is a good thing.
    - enraged_camel 11y ago
      Let me give a more concrete example: if something was developed in Rails 3 but was not updated for Rails 4, then I assume it won't work (I'm on Rails 4.1). This doesn't mean the entire project needs to be re-written. Often times, a simple note that says "compatible with Rails 4" would be satisfactory. But if even the readme is not updated, that makes it difficult for me to put any faith in it. And unfortunately there are tons of projects like that on GitHub.
chilicuil 11y ago
Yeah, it's hard to have a productive life with always moving targets. With git, github and software managers pulling directly from it (although a decentralization way could be even better), I wish we get more often software by hash so we stop worrying less about copping with new changes and more about doing what matter to us.
panadolkey 11y ago
Run of the mill software exhibit life cycle patterns more like a small animal. It starts out all nimble and has to grow and change over time to become an adult of its kind; then it eventually dies. Finishing your projects is good advice overall though.
JustSomeNobody 11y ago
A lot of people equate "done" as "abandoned". Wasn't there some ruffled feathers between Rob Conery and some user over Massive being "done"? But, then, who wants those kinds of users, right?
iambot 11y ago
But its so hard! :) my strategy is to have many 3-9 side projects on at any one time, each is really just practice and I judge the concepts based on how often revisit them.
omouse 11y ago
I'm at the last 10% of a screencast script; there's two more phases after this but for some reason my productivity on the project has slowed to a crawl. I'm not sure how to overcome this feeling.
haberman 11y ago
The only way to "finish" software in the way the author describes is to find or invent an abstraction that is exceptionally powerful and well-designed. It has to give users what they want for a multitude of different use cases without requiring the library to grow to accommodate those use cases. In practice, abstractions this powerful and flexible are almost impossible to create. For example: - the Linux kernel is based around POSIX, which is a pretty good set of abstractions. But its API surface area is huge, and whenever users want to do something not in POSIX, the Linux developers have to invent a new syscall or stick more crap in /proc. - Lua is an exceptionally well-designed scripting language and implementation, that satisfies tons of use cases while staying small. But it keeps adding features to address pain points of existing users. For example, Lua 5.3 added integer support. Users wanted it. - zlib is perhaps the closest I can think of to a library truly being "done." And it gets away with this because it is perhaps one of the easiest abstractions to define and contain: a simple string->string streaming transformation that uses a roughly constant overhead of memory. That's pretty much as good as it gets!
- MichaelGG 11y ago
  Even zlib looks to be a bit more complex than that when doing streams of packet data: http://www.bolet.org/~pornin/deflate-flush-fr.html http://www.bolet.org/~pornin/deflate-flush-fr.html There's also stuff like preset dictionaries and so on so string->string is just one part of the abstraction and isn't a full signature. Compression level's another. zlib's also not competitive in many scenarios, so it's only "done" for limited scope.
rc4algorithm 11y ago
> Except for some basic UNIX tools, like grep or make, it's almost impossible to find anyting that's truly finished, not simply abandoned. Much of the stuff in the OpenBSD base. thttpd also comes to mind.
curiousjorge 11y ago
I don't know, lot of interviews I've been to in the past doesn't seem to value the fact that I spent almost 4 years of my life working on a single project (which will never be finished but pretty damn good by now) or that I've been selling and supporting customers with it. A basic memoization algorithm type questions or 'tell me about a time when you...' and I choke every god damn time while a fresh graduate with a CS degree breezes through it. I don't spend time on any of that when I'm working on a problem, it's important for me to build something that just works first in order to meet project deadline and then optimize afterwards but I guess this is not good for an employee point of view since they want someone who is more focused on producing code over product functionalities and features. At that point it would be useless if you've built something they can't look at the code (why the hell should I reveal proprietary information?). So basically I find myself with the ability to finish but unable to be hired as an engineer as I lack CS and experience writing code in an office environment. Contrary, finding freelance projects and landing work has always been far more easier, and I can maximize my value for my client and also myself, since it is tightly coupled to the ability to complete projects on time and solve problems. Pushing back deadlines because of disagreements over code formatting or technology choice is not how I want to spend my time.
- s73v3r 11y ago
  "it's important for me to build something that just works first in order to meet project deadline and then optimize afterwards but I guess this is not good for an employee point of view" That might be because they know that afterwards never comes.
kazinator 11y ago
The only software that gets truly finished is embedded firmware for small devices, which is done when it is debugged and covers all the conceivable use cases, and development stops. (The firmware may still generate new descendant code, but users have to get new hardware to get that code.) For much software, being finished is actually a kiss of death, because it is expected to keep improving and putting out new revisions. So "finished" is regarded as a synonym for "abandoned". "Finish your stuff" for that kind of software is a poor directive. Rather, it should be, "before each release, get your stuff into a state of completion whereby everything that is documented is implemented and vice versa, and the quality is good (bug-wise, etc)".
Walkman 11y ago
I can't think of a piece of software I wrote and feel finished, not because I abandoned them, but because I stop improving them when they are good enough for the task. Maybe it's just me but I never feel a software is finished. You can at least refactor it or add new funcionality, improve speed/readability/reliability until the end of time. It's like writing a book. You can always rephrase, add new characters improve the story, but you have to stop writing it sometime.
- oconnor663 11y ago
  In the end though, readability/maintainability end up being at odds with features/speed. I like to think about the hypothetical programmer that has to take over my project ten years from now. Is the value of a new feature worth their pain and suffering? Is my project going to be too painful to keep alive? I think the projects at http://suckless.org http://suckless.org have taken maintainability to a really inspirational level.
splaty 11y ago
I'm 5 years into the programming business and my own projects are just starting to get into a usable state in a reasonable amount of time. Finishing things feels a bit further away still. Thanks for the article.
danvoell 11y ago
A couple times today, I found myself in the middle of something and came back to HN to procrastinate. I saw the Finish Your Stuff headline and left to finish what I was doing. I need to have a little banner on top of my computer that says "finish your stuff"
- raldu 11y ago
  You may find noprocrast feature on HN settings page useful. It is a polite reminder that tells you to go back to work. You can adjust how many minutes you can stay at HN (maxvisit), and when you can come back (minaway).
chipsy 11y ago
I currently approach it from the "cyclical" time-management model. I'll know that things are never finished, but what I can do is finish a sketch of a broad system, or a detailing of a smaller portion, and return to it later. Repeating that a few times gets very powerful results. What never works is when I start building an eternal software edifice. My name is Ozymandias, king of kings...
halayli 11y ago
We share this problem with painters. It's hard to know if it needs a final brush touch or it's done.
hobarrera 11y ago
This is the sort of wisdom that's really hard to pass on. I've learnt this from experience, and many other have. But when we try to pass this on to new programmers, the message never quite reaches them until they've learnt in by experience.
raggiskula 11y ago
Just leaving this here, side project comic strip http://www.commitstrip.com/wp-content/uploads/2014/11/Strip-Side-project-650-finalenglish.jpg http://www.commitstrip.com/wp-content/uploads/2014/11/Strip-...

406 points by cjg 11y ago

sova 11y ago

Some very practical, down-to-earth, solid advice. Lines I found insightful: "... make it functionally complete in the first place. ... 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." ^_^ I really like the idea of splitting a project into phases. You might have Three phases, each one building on the last, but the very first complete phase should be a complete and usable thing in itself. First the skateboard, then the scooter, then the bike, the motorcycle, and finally the car.

soft_dev_person 11y ago
If I ever buy a car with skateboard as a chassis, I'll be very disappointed! Sorry, just had to =)
- bbcbasic 11y ago
  Probably it should be build the tyre first. This is a functionally complete thing that can, along with many other functionally complete things be composed into the car.
  - kbutler 11y ago
    Car built with scooter tires... Scooter built with car tires... Just not seeing it. When Java was first becoming popular, I recall emphasizing how important it was to use the standard, well-documented, well-tested java.lang.String, rather than a custom String class as had been done in C++. Application domain experts started asking about strings that didn't fit in RAM (documents). A great, tested component in one domain may require a significant redesign in a domain with other requirements.
    - sova 11y ago
      Coding is a conceptual art-form, it's not about building a car with scooter tires, it's about upgrading vehicles to get the end result in a workable fashion. Try using spark plugs and pistons to get somewhere!
    - bbcbasic 11y ago
      Car built with car tyres. Analogy wears thing because a tyre is a standard off the shelf thing. In software everything that is interesting (and requires employees) is custom to some degree. So it is like a tyre for a rover on the moon. However no need to get that to also work for a scooter on pluto! Unless the sales guy has already promised it!
  - sova 11y ago
    step 1 "invent the wheel"
  - lmm 11y ago
    No, you miss so much when you try to make a component you think will be useful. The first piece must be something that makes someone's life a little bit easier - that's the only way to be sure you're making something actually useful.
pdpi 11y ago
> First the skateboard, then the scooter, then the bike, the motorcycle, and finally the car. I've always found this metaphor incredibly amusing, because, to me, it actually highlights the _problems_, rather than advantages, of the iterative approach. At every step of the process, you're not only increasing complexity, you're also pivoting your product to the point where: 1. your previous clients are unlikely to still be well served by the new product, and are likely to churn as a result 2. the engineering challenges are different enough that most of the components aren't really reusable, and trying to shoehorn one stage into becoming the next will give you a sub-par product.
- sova 11y ago
  It's not about incremental development, it's about passing the baton. The spirit is motion/movement/transport, and the corresponding vehicle should be a natural expression of that with your available tools. Who said that the goal should be product-oriented? If I want to reach Alaska I will gladly take whatever transportation suits me best at the time. If I were insistent that my tank was clearly the most capable vehicle, although I would eventually get there, it would not be as enjoyable, imho.
rumcajz 11y ago
Aside of it being convenient for users, keeping the components small is good for the developer as it tends to tame the complexity to the acceptable level.

shabbyrobe 11y ago

What does this mean for the future of nanomsg's development?

rumcajz 11y ago
The project was take over by Garrett D'Amore so it's up to him to decide on its future.
- shabbyrobe 11y ago
  Thanks for the reply. Are you still involved in any capacity or have you decided to move on from the project entirely?

melling 11y ago

"Real artists ship" "if you are not embarrassed by the first version of your product, you've launched too late" https://en.m.wikipedia.org/wiki/Release_early,_release_often https://en.m.wikipedia.org/wiki/Release_early,_release_often I'm sure there are many others, but these ones keep me shipping.

georgerobinson 11y ago
If you're embarrassed by the first version of your product (i.e. suppose it's buggy, or is lacking in it's UI) then it's probably not ready to ship? There is nothing worse than shipping a half-baked product.
- keyle 11y ago
  I think you're both right. And knowing the right balance is the key.
  - melling 11y ago
    Reid Hoffman: https://pbs.twimg.com/media/Bldr6K1IEAAzeSl.jpg:large https://pbs.twimg.com/media/Bldr6K1IEAAzeSl.jpg:large
    - emodendroket 11y ago
      Thanks. I had trouble reading it in text form, but now that it's an image that includes a guy's head I get the point.
      - melling 11y ago
        I thought there was some confusion about who the credit for the quote went to. People weren't referring to Reid by name. The link was simply the first Google result that I clicked. Random.
    - VSpike 11y ago
      In the case of LinkedIn, the world might have been a better place if they'd never shipped at all.

Kenji 11y ago

Slightly OT, but Except for some basic UNIX tools, like grep or make Is make a basic tool? I'm often surprised when I find out new features of make that I was unaware of. I feel like it's bigger than it appears to be.

emmelaich 11y ago
I consider make a basic tool. So much of programming and administration is about managing dependencies, and make is the default tool. Such a pity it has a shitty syntax.
- berntb 11y ago
  There is no reason for Make to have a "shitty syntax", since it would be easy to have an alternative syntax -- which make recognized and handled differently. (So make would be backwards compatible.) With the way software updates percolates out in distros, a new make format could be supported in five years on most every server and desktop everywhere. I think the reason this haven't happened after decades is because make works. If you want to prove me wrong, read previous paragraphs. If you succeed, I'll buy you a beer. Hell, we should all buy you a beer if you improve our life quality. :-) (Yeah, I'm hellbanned.)
sitkack 11y ago
Basic doesn't necessarily mean simple. In this context, I think it refers to a low level building block.
lmz 11y ago
Those features are probably extensions. The POSIX specification for make is quite simple: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ma...

amelius 11y ago

> You bought a damned chair and you want it to remain a chair, not to find out that it's some kind of protean piece of furniture that's a chair today and partly a table tomorrow and, who knows, maybe you'll be able to humidify your cigars in it next week. This is exactly my problem with web-services (and software that auto-updates itself).

HappyTypist 11y ago
Every software is like this to some extent. The more external stuff they link, the more affected. Even if something doesn't auto update, eventually you'll have to update to the latest version because certain functionality will no longer work the way it should. Sure, you can fork it, but many software projects take more than one person to maintain.
emodendroket 11y ago
I wish more software updated itself. I don't want to navigate to the download page and run the installer every time it updates. That's busywork.
- dublinben 11y ago
  This is already a solved problem with package managers. You shouldn't ever have to "run the installer" each time you need to update a program.
  - orkoden 11y ago
    The software in my package managers' sources is outdated.

onion2k 11y ago

There's a great list of project management advice by Jerry Madden of NASA that gets posted here occasionally[1]. One of the points is; "Rule #30: It is mainly the incompetent that don't like to show off their work." Madden's remark is based on the specific environment he was involved in (NASA engineering); if you're surrounded by people who are good at their jobs and who know how to criticise constructively then there aren't many reasons to hide what you're doing other than it being a bit rubbish. I don't entirely agree with the idea that people who don't show things off are necessarily incompetent, especially if showing off your work means putting it under general public scrutiny (who can be very nasty), but there's a huge amount of value to be gained in getting feedback from your peers as early as possible. [1] http://www.nasa.gov/pdf/293253main_62682main_jerry_madden_forum7.pdf http://www.nasa.gov/pdf/293253main_62682main_jerry_madden_fo... (Non-PDF version: http://www.altisinc.com/resources/rules/ http://www.altisinc.com/resources/rules/ )

mironathetin 11y ago
There are other important reasons not to show things before they are done: one is the impatient group member who rather refocuses a development than to wait until it converges to something usable. It takes a lot of experience to make a realistic guess, how long software projects take. It also takes a lot of experience to put progress reports in a way that it always looks like great things are happening in order to avoid the refocus discussion. The all important point is a constructive team that knows their job. But especially in space project related development, you may be surprised to find managers who don't know much about software.
- wiz21c 11y ago
  I'd say it is a better idea to show something finished (or if it's too big, a part of it that it finished). Because if it's not finished, those who look at it will have hard time to understand where you are, where you can go and thus they'll have hard time making a good review of it, or worse, they'll associate the unfinished stuff to your incompetence, lack of vision, lack of will, whatever.
objectified 11y ago

mironathetin 11y ago

"Lately, after 30 years in the programming business, I've finally managed to cut down my projects to a reasonable size." ... long before those thirty years, someone who thinks he is a great manager may take over the steering wheel (he or she). And things are ready to start from the beginning. Im my group, we have another flavour of not finishing things: managing by whatever is in front of the managers mind and declare it highest priority. This is the best way to work hard all the time and get nothing done at all. Well, we all read peopleware a long time ago, all except of the managers. Anybody here, who has a good idea how to handle these traps?

otherusername2 11y ago
> managing by whatever is in front of the managers mind and declare it highest priority Bane of my existence for the longest time. Eventually I learned to just ignore those managers. They're too chaotic to remember whatever I was supposed to work on for them anyway.
- mironathetin 11y ago
  Ignoring seems to me like the secret weapon of the powerless. I like to confront, discuss and get things improved. But it is so hard to get incompetent managers up to speed, if they lack years of experience.
  - otherusername2 11y ago
    > the secret weapon of the powerless It is. I've had a few managers where everything we all tried to change change were fruitless. The only solution was to either antagonize until things got out of hand, or to ignore. > I like to confront, discuss and get things improved That's a good initial starting point. But I've also learned that there comes a time when expending any more of my own energy fighting such people is no longer worth it. > incompetent managers In my cases, it wasn't incompetence but rather character. You can have rational discourse with incompetent people. You can show them why they're wrong. You can't have a reasonable discussion with someone who's own mind jumps from high-priority to high-priority, wanting everything yesteryear but isn't willing to put in the actual resources to get things done. I've dealt with too many managers like that to expend much energy on it anymore. Mind you, ignoring them should be a last resort, but given enough experience with such managers, you learn to quickly know when you're dealing with one. I'd much rather spend my time making customers happy.

z3t4 11y ago

If you think "giving up" on a project is easy. Try "giving up" on your "dreams", those project you work on every day, even though you know you wont make it.

gedrap 11y ago

In my own experience, I found the following 2 things being the most important: 1) Keep it fun. Sometimes you start working on something and a week later you realize it's not as great as you expected it to be. Maybe you are working on some game and you can see it won't be as fun to play as you thought, etc. It's fine, it's ok to stop working on it. Forcing yourself to work on it won't produce any good. 2) Start with well defined, small goals. Define v1.0 which would contain only the most critical features, ship it (even if it means simply tagging on git). There's something hugely motivating about completing things, no matter how simple they are. EDIT. One more thing I'd add, when working on a side project, don't start thinking about how everyone will be using, how many thousands of github stars it will have, whatever. It doesn't even have to be actually useful, as long as you have good time and learn something on the way. I've worked on a few projects that I'd say are totally useless (such as https://github.com/GedRap/xs-vm https://github.com/GedRap/xs-vm ) but at the same time I see them as successful because a) had great time b) learned something new, even if it's some small details about a library or a language.

TheOtherHobbes 11y ago
I've found: 1) Usually getting something finished is a boring slog. You get the (you think...) brilliant idea phase when you're all fired up, then you get "this is really boring" phase when you're working your way through a thicket of problems, squashing bugs, finding new bugs, thinking you should refactor (you shouldn't, usually) and completion seems like an ever-receding goal. 2) Break big goals into smaller goals. Repeat recursively until done. Then do it some more, because you missed a few things. Sweat the small stuff, because when you glue it all back together and you've worked through phase 1 properly, the big stuff just works. (Or near offer, anyway.) Keep the cognitive load low: small microprojects and problems, one at a time. It's not unusual to have problems with phase 1. But it's also the difference between being a professional and being a hobbyist. If you just keep starting new projects when you hit phase 1, you don't ship.
- gedrap 11y ago
  Valid point, I totally see what you mean. >>> You get the (you think...) brilliant idea phase when you're all fired up, then you get "this is really boring" phase. In my experience, there are 2 kinds of 'really boring' phase. One kind, as you mention it, is the less exciting part of the work, be it writing docs, or some edge case bugs, etc. The other kind is when you discover that you largely underestimated the complexity, or saw some major flaws in the initial idea. Like I've mentioned in my previous comment, maybe you start working on a game and find out some major flaws in the gameplay and can't see it being a fun game to play anymore. While it's not always obvious which case you are facing, in the later case, in my opinion, it's fine to halt the project. If you don't believe in it, nothing good will come out of it. >>> It's not unusual to have problems with phase 1. But it's also the difference between being a professional and being a hobbyist. I guess it depends on what's the purpose of the side projects. If it's something you try to make a business of (passive income kind of thing), then yeah you totally should get a bit of extra will power to get it shipped. But if it's something that is done just for fun, then I wouldn't sweat it that much.

wainstead 11y ago

I thought the Unix philosophy embraced the idea of "small tools that do one thing really well." > Please join me in my effort and do finish your projects. Hear, hear. A friend and I hosted a "Finish it! Weekend" once (as opposed to a "Startup Weekend"). The idea was to get people together for one weekend and finish that last 10% or whatever of a project. Sadly we were the only two to show up. (And we both finished our projects, which suggests this might be a good kind of hackathon to host every six months or so).

voltagex_ 11y ago
Would you consider hosting that with remote participants? I'd love to do a *thon like that.
- rafaqueque 11y ago
  That's a very good idea. I'm up for that, remotely.
- wainstead 11y ago
  Sure! What kind of "venue" would you suggest? (Lord knows I have plenty of unfinished projects myself!)
  - S4M 11y ago
    A dedicated chan on IRC maybe? EDIT: Also: I might take part if the "Finish it" weekend takes place, provided my wife takes care of the kids long enough.
  - voltagex_ 11y ago
    If you wanted to make this big you could get a whole lot of hackerspaces to participate. I'd suggest IRC for now.
prawn 11y ago
Nice idea. Call it a "FinishUp Weekend" as opposed to a "StartUp Weekend"?

qznc 11y ago

The point of the article is not "Finish your stuff", but "Tackle smaller problems".

cafebeen 11y ago
That sounds more in line with the unix philosophy!

pfortuny 11y ago

Oh, come on: software is usually much more than a table or a chair. It grows, it needs care, it is more like a plant than something static. What does it even mean to "finish" a program like 'ls' given the increasing complexity of filesystems with time?

Loque 11y ago
I caught myself thinking the same thing, however if you compare software to a physical product the importance of the analogy remains intact. It may not apply to you however, I have been lucky enough to be surrounded by some very well disciplined developers who make a point of finishing a lot of what they start to varying degrees of success.
vezzy-fnord 11y ago
The semantics of POSIX dirents haven't really changed, and any file system complexity is abstracted by the kernel's VFS subsystem to provide generic data in all cases. So, yes, it is possible for something like 'ls' to be finished, or at least for really long times.
- pfortuny 11y ago
  Ok, yes, my example was not the best one. But at the same time, consider things like UTF-8, localization, etc. They appear at the least expected moment and someone has to do something unless the tool becomes useless. I understand you get the idea, though.

jsingleton 11y ago

The Zero MQ guys seem to have some pretty good wisdom to impart. Pieter Hintjens has a free book at http://cultureandempire.com http://cultureandempire.com which is worth a read.

brudgers 11y ago
The ØMQGuide itself is pretty awesome, too. http://zguide.zeromq.org/page:all http://zguide.zeromq.org/page:all
vidarh 11y ago
The iMatix guys have been amongst my heroes since they released Libero (state machine code generator) and built Xitami on it (both mentioned by Hintjens as "finished" projects in a comment to the linked article) back in the 90's...
- vanessa98 11y ago
  Why is there so much dysfunction around everything they do?
  - vidarh 11y ago
    Is there? Care to expand?

jblok 11y ago

"Lately, after 30 years in the programming business, I've finally managed to cut down my projects to a reasonable size." After 30 years of programming, you'd better be a pretty decent programmer. And maybe that's why their projects take less time to complete.

vidarh 11y ago
If you look at his progression, a lot of it is also about shaving down the size and complexity. E.g. the AMQP -> 0mq -> nanomsg chain which is a journey of cutting complexity.

linux_devil 11y ago

Very good read , particularly comparison of chair with product in first few lines was opener .

euphemize 11y ago

I like this idea, but I'm not sure it's realistic. Constraints change all the time, just like your users' needs. In principle this works, but I'm not convinced that everything should aim to be finished.

rdtsc 11y ago

Is nanomsg finished? I found its Windows support rather broken -- failing test cases. Strange lockups. https://github.com/nanomsg/nanomsg/issues https://github.com/nanomsg/nanomsg/issues I do not see Martin working much on those these days. Does anyone know how untangle those state machines besides him.

shepardrtc 11y ago
Martin has passed the reins on to Garrett D'Amore, but I would say the majority of the project is finished.
vidarh 11y ago
See his comment in the comments on what he thinks about how to decompose nanomsg, it's quite interesting.

ams6110 11y ago

Just an aside on the carpenter metaphor, there's sort of a running joke that a carpenter's house is never finished. It's not just the software profession that has this problem.

innguest 11y ago
But as the carpenter goes on doing his stuff, the things he did stay put. They do not suddenly become incompatible with each other, or need to be maintained daily. Carpentry is orders of magnitude less brittle. It doesn't even compare. Programming is more like policy writing. Definitely not like carpentry.

emodendroket 11y ago

Now what if your home regularly changed in such a way that your old chairs didn't sit upright anymore? There are limits to the carpentry analogy.

rumcajz 11y ago
If your chair covers the area of Los Angeles, it'll sure have problems with changing landscape. If it's a regular-sized chair, less so.
- emodendroket 11y ago
  Yes, but now we've clearly abandoned the familiarity of the analogy, making it less clear how much value the analogy has in illuminating what we're trying to say.
artmageddon 11y ago
Right, and even the use cases for software can change in such a way that it can influence the entire architecture. "We want to design a simple rocking chair for a sweet elderly couple." becomes "We need to make enhancements to this chair to equip it with an ejection seat suitable for a fighter pilot in a jet. No, you can't start over either, there isn't enough in the budget for that."
vidarh 11y ago
In which case perhaps the reasonable solution is for you to get a different type of chair, rather than trying to modify your old chairs to fit the changing requirements.

netcraft 11y ago

Am I the only one that really hates the carpenter analogy? As someone who does woodworking on the side of my programming, there's a million reasons why it's a terrible way to think about software development. The chair doesn't have supported platforms, new security issues, or the need to be updated so that people keep buying the same chair. Someone else isn't going to have to come along later to maintain the chair and have to be knowledgeable about the specific tools that the chair was built with.

emodendroket 11y ago
Don't forget that a programmer's work is not really like making three of the same chair either. Maybe if every single thing the carpenter made was a highly customized bespoke piece.
diminish 11y ago
Carpenter analogy is as bad as the "book author" analogy. You write a book and let it go. Nothing to support, all updates are to be paid by customers in a new release.
- clord 11y ago
  "Book author" is at least closer to the truth. There are editions and old copies floating out there, it's hard to estimate completion dates, and authors have many of the same copyright problems. The difference is that software must live in a dynamic and shifting 'house' where everything gets rearranged by vendors, probed for weaknesses by attackers, and new features are constantly demanded by the users. Solutions to all of this are tacked on as an endless stream of appendices. Throw in patents for extra insanity. Both analogies strain to fit this reality. Edit: That brings me back to the article. "Finishing software" just means we should act more like authors. Very hard to achieve when you think of the differences above.
  - stephengillie 11y ago
    Some books do have versions (textbooks et al), some books are out-of-date as soon as they are published (statistics, science). Many would benefit from a reduction in lines and becoming more concise. Some are a jumbled mess that's basically useless, but nobody wants to update them.

kefka 11y ago

> Imagine the carpenters were like programmers. So, they do the work for free, and updates as long as people keep using it? Terrible analogy.

jdimov9 11y ago

This is absurd. A finished project is a dead project. If it isn't improving, it's dying. Never finish your projects (unless you're just doing homework). Software is a system. Systems of any non-trivial complexity are living things that must adapt and evolve. Constantly. (Also, there is absolutely nothing wrong with abandoning a project. Gain as much as you can from your experience and quickly move on to something better / more meaningful.)

firethief 11y ago
Is TeX dead?
- jdimov9 11y ago
  You had to fish hard for this example, didn't you? Sometimes, genius strikes and you get something so precisely thought out and so well executed that it lasts for generations. Still, I'd have to answer your question in the affirmative. The original TeX is quite dead indeed. It (and the ecosystem around it) have evolved significantly over the years and continue to evolve as we speak, so it is far from finished.
- lmm 11y ago
  Given the state of its unicode support, yes.
vidarh 11y ago
By that token a substantial proportion of the tools I rely on on a daily basis are dead. (not least if you consider the actual contents of the linked article, which makes it clear that by "finish" he means to make it functionally complete, not to stop fixing bugs or e.g. ensuring it still compiles)
segmondy 11y ago
Your comment is absurd. "A finished project is a dead project?"
- jdimov9 11y ago

rlpb 11y ago

I find it irritating when people look at some of my projects on Github and consider then "abandoned" because they haven't had any commits in a year or two. They're not abandoned: they're finished. They do what they're designed to do, and I use them regularly. Outstanding issues may exist for feature requests that I don't need, or for minor bugs that won't occur in anything but obscure edge cases that don't apply to the primary use case. I welcome high quality patches but otherwise have no interest in pursuing them.

enraged_camel 11y ago
If it's anything you expect other people to use, then I'd consider anything that hasn't been updated in the past year "abandoned", yeah. If it's your personal projects though, I don't make that assumption.
- vidarh 11y ago
  I have several projects that haven't been updated in more than a year which are still maintained in the sense that if there are bugs, I fix them. They are rarely touched for a simple reason: They do what they're meant to, and they still work. I wish more software took that approach. Far too often software quality drops after a while as developers keep piling on the features.
- nathan_long 11y ago
  Abandoned or stable? If it has no dependencies and a small feature set, it may just be done. "Stable" is a good thing.
  - enraged_camel 11y ago
    Let me give a more concrete example: if something was developed in Rails 3 but was not updated for Rails 4, then I assume it won't work (I'm on Rails 4.1). This doesn't mean the entire project needs to be re-written. Often times, a simple note that says "compatible with Rails 4" would be satisfactory. But if even the readme is not updated, that makes it difficult for me to put any faith in it. And unfortunately there are tons of projects like that on GitHub.

chilicuil 11y ago

Yeah, it's hard to have a productive life with always moving targets. With git, github and software managers pulling directly from it (although a decentralization way could be even better), I wish we get more often software by hash so we stop worrying less about copping with new changes and more about doing what matter to us.

panadolkey 11y ago

Run of the mill software exhibit life cycle patterns more like a small animal. It starts out all nimble and has to grow and change over time to become an adult of its kind; then it eventually dies. Finishing your projects is good advice overall though.

JustSomeNobody 11y ago

A lot of people equate "done" as "abandoned". Wasn't there some ruffled feathers between Rob Conery and some user over Massive being "done"? But, then, who wants those kinds of users, right?

iambot 11y ago

But its so hard! :) my strategy is to have many 3-9 side projects on at any one time, each is really just practice and I judge the concepts based on how often revisit them.

omouse 11y ago

I'm at the last 10% of a screencast script; there's two more phases after this but for some reason my productivity on the project has slowed to a crawl. I'm not sure how to overcome this feeling.

haberman 11y ago

The only way to "finish" software in the way the author describes is to find or invent an abstraction that is exceptionally powerful and well-designed. It has to give users what they want for a multitude of different use cases without requiring the library to grow to accommodate those use cases. In practice, abstractions this powerful and flexible are almost impossible to create. For example: - the Linux kernel is based around POSIX, which is a pretty good set of abstractions. But its API surface area is huge, and whenever users want to do something not in POSIX, the Linux developers have to invent a new syscall or stick more crap in /proc. - Lua is an exceptionally well-designed scripting language and implementation, that satisfies tons of use cases while staying small. But it keeps adding features to address pain points of existing users. For example, Lua 5.3 added integer support. Users wanted it. - zlib is perhaps the closest I can think of to a library truly being "done." And it gets away with this because it is perhaps one of the easiest abstractions to define and contain: a simple string->string streaming transformation that uses a roughly constant overhead of memory. That's pretty much as good as it gets!

MichaelGG 11y ago
Even zlib looks to be a bit more complex than that when doing streams of packet data: http://www.bolet.org/~pornin/deflate-flush-fr.html http://www.bolet.org/~pornin/deflate-flush-fr.html There's also stuff like preset dictionaries and so on so string->string is just one part of the abstraction and isn't a full signature. Compression level's another. zlib's also not competitive in many scenarios, so it's only "done" for limited scope.

rc4algorithm 11y ago

> Except for some basic UNIX tools, like grep or make, it's almost impossible to find anyting that's truly finished, not simply abandoned. Much of the stuff in the OpenBSD base. thttpd also comes to mind.

curiousjorge 11y ago

I don't know, lot of interviews I've been to in the past doesn't seem to value the fact that I spent almost 4 years of my life working on a single project (which will never be finished but pretty damn good by now) or that I've been selling and supporting customers with it. A basic memoization algorithm type questions or 'tell me about a time when you...' and I choke every god damn time while a fresh graduate with a CS degree breezes through it. I don't spend time on any of that when I'm working on a problem, it's important for me to build something that just works first in order to meet project deadline and then optimize afterwards but I guess this is not good for an employee point of view since they want someone who is more focused on producing code over product functionalities and features. At that point it would be useless if you've built something they can't look at the code (why the hell should I reveal proprietary information?). So basically I find myself with the ability to finish but unable to be hired as an engineer as I lack CS and experience writing code in an office environment. Contrary, finding freelance projects and landing work has always been far more easier, and I can maximize my value for my client and also myself, since it is tightly coupled to the ability to complete projects on time and solve problems. Pushing back deadlines because of disagreements over code formatting or technology choice is not how I want to spend my time.

s73v3r 11y ago
"it's important for me to build something that just works first in order to meet project deadline and then optimize afterwards but I guess this is not good for an employee point of view" That might be because they know that afterwards never comes.

kazinator 11y ago

The only software that gets truly finished is embedded firmware for small devices, which is done when it is debugged and covers all the conceivable use cases, and development stops. (The firmware may still generate new descendant code, but users have to get new hardware to get that code.) For much software, being finished is actually a kiss of death, because it is expected to keep improving and putting out new revisions. So "finished" is regarded as a synonym for "abandoned". "Finish your stuff" for that kind of software is a poor directive. Rather, it should be, "before each release, get your stuff into a state of completion whereby everything that is documented is implemented and vice versa, and the quality is good (bug-wise, etc)".

Walkman 11y ago

I can't think of a piece of software I wrote and feel finished, not because I abandoned them, but because I stop improving them when they are good enough for the task. Maybe it's just me but I never feel a software is finished. You can at least refactor it or add new funcionality, improve speed/readability/reliability until the end of time. It's like writing a book. You can always rephrase, add new characters improve the story, but you have to stop writing it sometime.

oconnor663 11y ago
In the end though, readability/maintainability end up being at odds with features/speed. I like to think about the hypothetical programmer that has to take over my project ten years from now. Is the value of a new feature worth their pain and suffering? Is my project going to be too painful to keep alive? I think the projects at http://suckless.org http://suckless.org have taken maintainability to a really inspirational level.

splaty 11y ago

I'm 5 years into the programming business and my own projects are just starting to get into a usable state in a reasonable amount of time. Finishing things feels a bit further away still. Thanks for the article.

danvoell 11y ago

A couple times today, I found myself in the middle of something and came back to HN to procrastinate. I saw the Finish Your Stuff headline and left to finish what I was doing. I need to have a little banner on top of my computer that says "finish your stuff"

raldu 11y ago
You may find noprocrast feature on HN settings page useful. It is a polite reminder that tells you to go back to work. You can adjust how many minutes you can stay at HN (maxvisit), and when you can come back (minaway).

chipsy 11y ago

I currently approach it from the "cyclical" time-management model. I'll know that things are never finished, but what I can do is finish a sketch of a broad system, or a detailing of a smaller portion, and return to it later. Repeating that a few times gets very powerful results. What never works is when I start building an eternal software edifice. My name is Ozymandias, king of kings...

halayli 11y ago

We share this problem with painters. It's hard to know if it needs a final brush touch or it's done.

hobarrera 11y ago

This is the sort of wisdom that's really hard to pass on. I've learnt this from experience, and many other have. But when we try to pass this on to new programmers, the message never quite reaches them until they've learnt in by experience.

raggiskula 11y ago

Just leaving this here, side project comic strip http://www.commitstrip.com/wp-content/uploads/2014/11/Strip-Side-project-650-finalenglish.jpg http://www.commitstrip.com/wp-content/uploads/2014/11/Strip-...