I thought the Unix philosophy embraced the idea of "small tools that do one thing really well."<p>> Please join me in my effort and do finish your projects.<p>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).
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.
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.<p>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.
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;<p>"Rule #30: It is mainly the incompetent that don't like to show off their work."<p>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 <i>entirely</i> 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 <i>from your peers</i> as early as possible.<p>[1] <a href="http://www.nasa.gov/pdf/293253main_62682main_jerry_madden_forum7.pdf" rel="nofollow">http://www.nasa.gov/pdf/293253main_62682main_jerry_madden_fo...</a> (Non-PDF version: <a href="http://www.altisinc.com/resources/rules/" rel="nofollow">http://www.altisinc.com/resources/rules/</a> )
"Real artists ship"<p>"if you are not embarrassed by the first version of your product, you've launched too late"<p><a href="https://en.m.wikipedia.org/wiki/Release_early,_release_often" rel="nofollow">https://en.m.wikipedia.org/wiki/Release_early,_release_often</a><p>I'm sure there are many others, but these ones keep me shipping.
> 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.<p>This is exactly my problem with web-services (and software that auto-updates itself).
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.<p>In practice, abstractions this powerful and flexible are almost impossible to create. For example:<p>- 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.<p>- 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.<p>- 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!
In my own experience, I found the following 2 things being the most important:<p>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.<p>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.<p>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 <a href="https://github.com/GedRap/xs-vm" rel="nofollow">https://github.com/GedRap/xs-vm</a> ) 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.
"Lately, after 30 years in the programming business, I've finally managed to cut down my projects to a reasonable size."<p>... 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.<p>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.<p>Anybody here, who has a good idea how to handle these traps?
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.
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.<p>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.
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.<p>What does it even mean to "finish" a program like 'ls' given the increasing complexity of filesystems with time?
Is nanomsg finished?<p>I found its Windows support rather broken -- failing test cases. Strange lockups.<p><a href="https://github.com/nanomsg/nanomsg/issues" rel="nofollow">https://github.com/nanomsg/nanomsg/issues</a><p>I do not see Martin working much on those these days. Does anyone know how untangle those state machines besides him.
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.)<p>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".<p>"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)".
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"
The Zero MQ guys seem to have some pretty good wisdom to impart. Pieter Hintjens has a free book at <a href="http://cultureandempire.com" rel="nofollow">http://cultureandempire.com</a> which is worth a read.
Some very practical, down-to-earth, solid advice.<p>Lines I found insightful:
"... make it functionally complete in the first place.<p>... 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."<p>^_^<p>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.<p>First the skateboard, then the scooter, then the bike, the motorcycle, and finally the car.
> Except for some basic UNIX tools, like grep or make, it's almost impossible to find anyting that's truly finished, not simply abandoned.<p>Much of the stuff in the OpenBSD base.<p>thttpd also comes to mind.
Yeah, it's hard to have a productive life with always moving targets.<p>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.
A lot of people equate "done" as "abandoned". Wasn't there some ruffled feathers between Rob Conery and some user over Massive being "done"?<p>But, then, who wants those kinds of users, right?
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.<p>Thanks for the article.
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.<p>What never works is when I start building an eternal software edifice. My name is Ozymandias, king of kings...
Just leaving this here, side project comic strip
<a href="http://www.commitstrip.com/wp-content/uploads/2014/11/Strip-Side-project-650-finalenglish.jpg" rel="nofollow">http://www.commitstrip.com/wp-content/uploads/2014/11/Strip-...</a>
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.
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.<p>Finishing your projects is good advice overall though.
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.
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.
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.
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.
"Lately, after 30 years in the programming business, I've finally managed to cut down my projects to a reasonable size."<p>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.
Slightly OT, but<p><i>Except for some basic UNIX tools, like grep or make</i><p>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.
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.<p>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.<p>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?).<p>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.
This is absurd. A finished project is a dead project. If it isn't improving, it's dying.<p>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.<p>(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.)