I remember the old joke of emacs standing for Eight Megabytes (of RAM) And Constantly Swapping. Oh for the days when that was a lot of system memory.. Not really.
Eclipse is frankly a poor text editor. After learning enough Emacs to get comfortable, it becomes clear that there is a better way. For example, undo. In Eclipse, type something, undo it and type something else. Now you can't use the undo/redo function to get the first thing that you typed back. In Emacs, you can, since undo is an undoable operation. Similarly, having things like i-search, align-regex and rectangle editing have become vital for editing code. These things either do not exist, or are difficult to discover or use in things like Eclipse.
> Does having to 'build your own framework' (my paraphrasing of your point) typically mean your software delivery is slower?
Possibly, initially. However, probably not significantly, since you should only build the framework that you need.
> Is this detrimental to the business objective you're trying to achieve?
No, since the business objective is to make money. The software is the means to do that, and the choices you make today limit the markets that you can expand into. If you decide that you're making a mobile app for android, then you are going to have to do a bunch of work (possibly including re-implementing the app) to get into the iphone or desktop market.
> Does a 2-fold approach work - using a more substantial framework to begin with (for speed) followed by re-factoring into your own more specialised "framework of libraries" later?
I think that taking the framework away is very difficult. Even when you've replaced all the code, and no longer depend on it, you still have the basic shape that lingers. I think that we generally call that a "re-write".
> Definitely some food for thought in your point - I presume it's based on actual experience of programming under both regimes?
"Possibly, initially. However, probably not significantly, since you should only build the framework that you need."
OK, I have to throw a flag on this point.
Modern frameworks give you a lot of essential functionality OOTB. I've worked on enough home-brewed frameworks -- and indeed have been foolish enough once or twice to build my own. I've also used several great frameworks across a number of common languages.
If you can make an honest case that it's "probably not significantly" slower to roll your own framework as you develop an app than it would be to develop that same app on top of a great modern framework, then I'd love to hear it.
The software is the means to do that, and the choices you make today limit the markets that you can expand into.
I disagree with the whole sentiment around this.
First, the most critical market is the first one: until you get that, you aren't making any money.
Second, you can't guess what the changes will need to look like anyway, so any time spent preparing for the second market is time wasted from finding the first market.
The most i,portent factor in your decision really should be "How fast can I get done what I need to get done to survive as a business?"
Anything else is immaterial and really more about engineers focusing on technology instead of business.
>No, since the business objective is to make money. The
>software is the means to do that, and the choices you make >today limit the markets that you can expand into.
I guess then it's a question of the benefit of taking a tactical advantage vs. the opportunity cost of that decision (including the subsequent re-write)?
I would say that the risk of limiting future markets (or more specifically a prohibitive cost of entry into said markets) is only one of many risks that need to be considered in the decision making process.
Surely there are downsides to the inevitable re-invention of what a framework does if you roll-your-own? It's not a one-way bet.
The software choices we make also enable options whilst at the same time limit others - it's a trade off.
>If you decide that you're making a mobile app for android,
>then you are going to have to do a bunch of work (possibly
>including re-implementing the app) to get into the iphone
>or desktop market.
That's an interesting case (one I find myself peering at currently). Isn't the only real option to suck-up the fact that you'll need 3 versions on 3 platforms - or - build a product in a market that doesn't have diversity of platform as an issue (such as a browser-delivered app)? [That could be an argument against native apps on devices.]
I think that point is kinda conceded in the post. The problems arise when you get to some part of the framework that cannot be swapped out. In my experience, almost every project I've worked on has got to this point. The ones that didn't were small things that were basically 'done' in under 6 months. Software being 'done' tends to be a sign of a failing business, as you've run out of places to grow into, or things to optimise. That said, I've learned a lot from working with frameworks, and I would support your statement that frameworks are great for beginners.
Disclamer: I wrote the article, but didn't post it to hacker news
Didn't work for me (in chromium/fedora 14), I just saw the talking head and when the speech suggested I should be seeing something happen, nothing did.
