[l0st3d]

> 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?

yes

[encoderer]

"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.

[SoftwareMaven]

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.

[mattgreen]

>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.]