Just leaving this here, side project comic strip
http://www.commitstrip.com/wp-content/uploads/2014/11/Strip-...
Finish your stuff
171–177 of 177 posts
Re: Finish your stuff
#172Earlier quoted context omitted.
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...
Why is there so much dysfunction around everything they do?
Is there? Care to expand?
Re: Finish your stuff
#173Earlier quoted context omitted.
Abandoned or stable? If it has no dependencies and a small feature set, it may just be done. "Stable" is a good thing.
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…
That's a fine example. It has dependencies, the dependencies change quickly, so the project needs updating.
Let me give a counter-example. PriorityQueue is a data structure implementation published as a Ruby gem in 2005: https://rubygems.org/gems/PriorityQueue/versions/0.1.2. It has not been updated since, because it doesn't need to be. It just works. (It could use better docs, but even that would be a one-time change.)
Similarly, I have a gem that helps build searches with ORMs - https://github.com/nathanl/searchlight. It doesn't directly depend on any ORM, just the "chained method calls to build queries" interface that they implement. That means I don't need to update it when ActiveRecord or Sequel or Mongoid gets a new feature. Which means I commit far less often. I consider it feature complete and only make bug fixes, which should eventually stop.
At that point, it may look abandoned, but it won't be. Just stable. Which I consider a good thing.
Re: Finish your stuff
#174This 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 bet…
> A finished project is a dead project. If it isn't improving, it's dying.
Define 'improving', because there have been quite a few major projects that have been getting 'worse' (slower, buggier, less secure, more bloated, breaking changes, feature creep, inconsistent documentation) as time goes on. So what exactly are we prioritizing?
Wintel conquered the world by maintaining backwards compatibility. These days the majority of 'improving' seems to be for getting around breaking changes introduced by others and making unnecessary UI changes. Reliability and consistency is not a priority anymore. Instead no software can ever truly be finished because the assumptions under which it operates change unpredictably and inconsistently.
I mean really, once you finish something like a file renaming utility, what else is there to do? If it stops working due to changes made by someone else, then it needs to be updated, but that isn't improvement. If on the other hand it's working as intended, then the only way to further improve it is by changing priorities. Engineering is all about tradeoffs, but priorities are now being driven almost entirely by cultural forces, and I've seen this render working software inoperable for no other reason than it didn't fit the fashion of the time.
Reality doesn't change to the point that a chair, or even a microprocessor, stops working. Software on the other hand does, and if the platform you're targeting isn't stable, then you can never finish a project, let alone improve it. And this 'no updates' = 'dying project' philosophy is a big part of the problem, because it forces developers to unnecessarily update a project just so people believe it's relevant, while the only metric we should be using is that the software is fit for the purpose we use it for.
Re: Finish your stuff
#175Am 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 an…
> Am I the only one that really hates the carpenter analogy?
Apparently not, but the analogy is completely valid for what is being compared. A chair is designed for a specific purpose, so imagine if it kept changing in ways which were out of your control and either unrelated to, or made it less fit for, that purpose.
The problem I have is with how the article is using the term 'finished' to mean 'functionally complete', which is causing unnecessary confusion. Porting to new platforms and fixing security issues should not alter how functionally complete an app is, only address problems which either interfere with that purpose, or with the purpose of other apps running on the same system.
Even then, the article still isn't about functional completeness, but feature creep, and perhaps in the process the dangers of not using the right words for what you mean.
Re: Finish your stuff
#176I 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 ou…
> I thought the Unix philosophy embraced the idea of "small tools that do one thing really well." Big monoliths are too useful to go away. Does emacs "do one thing and do it well?" No, it does a million things, some of them better than others. Nevertheless, lots of Unix guys use it.
Perl is another counterexample (it was partly born from dissatisfaction with the Unix philosophy).
Re: Finish your stuff
#177Earlier quoted context omitted.
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.
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 doma…
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!