Agreed - I feel that as we have more filters, customisable searches, auto-folder moving and so-on then we're actually creating a big headache of curation, categorisation and taxonomy-creation for the end recipient.
What would be great IMO is for some of this to happen a little bit more automatically with the option for me to give the system feedback as to how well it did with it's filtering attempts. This would allow me to, over time, state my intentions (e.g. I really only want to be bothered with REAL problems) rather than implement the mechanisms to do so. I often feel I work for the machine - not the other way round.
Yeah I quite like the idea of using machine-learned automation to do categorization and filtering of information for us. It seems that this is an ideal role for the computer, an extension to the mind doing the hard/tedious work of curation and classification so we can just sit back and observe.
How do you reconcile the need to move fast initially to release a product or service in order to build the market for it from a business perspective?
Does having to 'build your own framework' (my paraphrasing of your point) typically mean your software delivery is slower?
Is this detrimental to the business objective you're trying to achieve?
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?
Definitely some food for thought in your point - I presume it's based on actual experience of programming under both regimes?
> 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.]
Hi, I like the ability to rapidly get started and quickly share (far better than Remember The Milk on that point).
There are other apps/services in competition but that is ok - proves there is some semblance of a market out there.
I'd say you should get it infront of as many potential customers as possible ASAP so you can move from hypothesizing about customers to having validated learning about them.
You're right to release early - you need to start qualifying WHO will pay and how MUCH pretty soon (if you wish to turn this into a profitable business).
Your unique selling point may well be the speed/ease of use and ease of sharing. I'd pay at least £1 per month for that.
Glad you can see there might be a niche for this kind of product. I'll take your pricing guidelines into account, and I may well reduce the pro account to be more in line with the users' expectations.
Sharing/ease of use is exactly my selling point, and it's one which not many similar apps out there have.
What would be great IMO is for some of this to happen a little bit more automatically with the option for me to give the system feedback as to how well it did with it's filtering attempts. This would allow me to, over time, state my intentions (e.g. I really only want to be bothered with REAL problems) rather than implement the mechanisms to do so. I often feel I work for the machine - not the other way round.