Comments on: Mobile back-end consulting? http://barelyenough.org/blog/2009/02/mobile-back-end-consulting/ … and there is much to be learned Thu, 02 Feb 2012 14:46:19 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Dick Brodine http://barelyenough.org/blog/2009/02/mobile-back-end-consulting/comment-page-1/#comment-70048 Dick Brodine Mon, 02 Mar 2009 18:15:14 +0000 http://barelyenough.org/?p=379#comment-70048 <p>You can develop an elegant, powerful API for mobile applications and attempt to sell it. I’ve tried something similar a couple of times. The Object-Oriented Project Size Estimation tool, Oopsize, written in Java, produces time estimates for the development of oo objects. We formed a company, put up a Web site, advertised, and wound up selling a single copy. We closed the company. Further down the road, I developed the Mathematical Server Sizing tool and published an article in IEEE “Computer” describing the mathematics of the tool. Once again, after a couple of years, it became clear that no one was going to buy the tool from me, even though the idea of the tool showed great utility. Today, the tool is freely available on Source Forge and I have like 800 users worldwide.</p> <p>I doubt that you can develop a viable program product on your own. Even if your idea is “dynomite” and the tool is well thought out and a great problem solver, it takes piles of money and connections to get your tool in front of someone that may actually buy it. If you’re curious, consider seriously how you intend to market your tool. Check out those costs. You absolutely will not believe what they charge for advertising. I thought I had a great advantage with the Server Sizing tool because it was written up in “Computer”. As it turns out, managers that could possibly authorize the purchase of such a tool actually can’t read, a fact I overlooked in my initial marketing plan. Please don’t quote that last comment on the Web. I’m trying to get a job, again.</p> <p>Sarcasm aside, developing both of these tools was a lot of fun. If you have the time and money to put something like this together, go for it. But I wouldn’t recommend quitting your day job, especially if other people are depending on you for financial support.</p> You can develop an elegant, powerful API for mobile applications and attempt to sell it. I’ve tried something similar a couple of times. The Object-Oriented Project Size Estimation tool, Oopsize, written in Java, produces time estimates for the development of oo objects. We formed a company, put up a Web site, advertised, and wound up selling a single copy. We closed the company. Further down the road, I developed the Mathematical Server Sizing tool and published an article in IEEE “Computer” describing the mathematics of the tool. Once again, after a couple of years, it became clear that no one was going to buy the tool from me, even though the idea of the tool showed great utility. Today, the tool is freely available on Source Forge and I have like 800 users worldwide.

I doubt that you can develop a viable program product on your own. Even if your idea is “dynomite” and the tool is well thought out and a great problem solver, it takes piles of money and connections to get your tool in front of someone that may actually buy it. If you’re curious, consider seriously how you intend to market your tool. Check out those costs. You absolutely will not believe what they charge for advertising. I thought I had a great advantage with the Server Sizing tool because it was written up in “Computer”. As it turns out, managers that could possibly authorize the purchase of such a tool actually can’t read, a fact I overlooked in my initial marketing plan. Please don’t quote that last comment on the Web. I’m trying to get a job, again.

Sarcasm aside, developing both of these tools was a lot of fun. If you have the time and money to put something like this together, go for it. But I wouldn’t recommend quitting your day job, especially if other people are depending on you for financial support.

]]> By: Peter Williams http://barelyenough.org/blog/2009/02/mobile-back-end-consulting/comment-page-1/#comment-69986 Peter Williams Sat, 28 Feb 2009 15:55:53 +0000 http://barelyenough.org/?p=379#comment-69986 <p>Michael, thanks for the feed back.</p> <p>I have plans for some posts articulating what I have found is important when developing APIs for mobile applications. They do have some limitations (e.g. they generally suffer from high latencies) that need to be taken into account but in many ways they are not particularly special (e.g. bandwidth is usually pretty reasonable).</p> <p>On the other hand, judging from the set of APIs on the internet today, the number of people that can actually design an decent API seems to be vanishing small. For mobile applications it is particularly important that APIs be well designed because of the limitations of the devices and the fact that once you release a version of the app that version will never go away.</p> Michael, thanks for the feed back.

I have plans for some posts articulating what I have found is important when developing APIs for mobile applications. They do have some limitations (e.g. they generally suffer from high latencies) that need to be taken into account but in many ways they are not particularly special (e.g. bandwidth is usually pretty reasonable).

On the other hand, judging from the set of APIs on the internet today, the number of people that can actually design an decent API seems to be vanishing small. For mobile applications it is particularly important that APIs be well designed because of the limitations of the devices and the fact that once you release a version of the app that version will never go away.

]]> By: Michael Buckbee http://barelyenough.org/blog/2009/02/mobile-back-end-consulting/comment-page-1/#comment-69971 Michael Buckbee Sat, 28 Feb 2009 06:34:44 +0000 http://barelyenough.org/?p=379#comment-69971 <p>I think you might need to consider your point #3 some more: if mobile apps are "just another" client, how much more value can you add to the development?</p> <p>Also, REST/HTTP has many kinds of awesomeness, but bandwidth friendliness is not typically one of them. Consider that many bandwidth constrained apps do things like send single bytes with the bits inside flipped as flags vs what bandwidth would be sucked up by running through the whole HTTP stack.</p> <p>I'm not trying to be pessimistic so much as just suggesting that you really need to articulate the expertise and benefit you could bring to a mobile > backend development above and beyond any other fat client > backend situation.</p> <p>Thanks,</p> <p>Mike</p> I think you might need to consider your point #3 some more: if mobile apps are “just another” client, how much more value can you add to the development?

Also, REST/HTTP has many kinds of awesomeness, but bandwidth friendliness is not typically one of them. Consider that many bandwidth constrained apps do things like send single bytes with the bits inside flipped as flags vs what bandwidth would be sucked up by running through the whole HTTP stack.

I’m not trying to be pessimistic so much as just suggesting that you really need to articulate the expertise and benefit you could bring to a mobile > backend development above and beyond any other fat client > backend situation.

Thanks,

Mike

]]>