<div dir="ltr"><div><div>I think you're mostly right but missing the larger point here.  Mobile platforms aren't like their much more open desktop brethren.  In the world of mobile you more or less get the tool chain provider by the vendor (Java, Objective-C or Swift) for native apps.  While I expect professional developers could easily pick up those languages, mastering tools takes time and Joe was initially looking for someone more ready to "jump in".<br>

<br></div>To provide an analogy more apropos to this list, I make my living working on Linux and generally working in Ruby.  Those are both just tools and given my background I wouldn't hesitate to tell a prospective employer I could pick up Solaris and Python if that's the stack they use.  However, even with significant experience fully learning that stack would take time and make me a bad fit for contracting work.<br>

<br></div>As far as Joe's project being "over-specced" in any case the spec is what it is.  When I refered to the "just one more thing" problem before I meant the same thing I think you mean when you say it's overspec'ed, there's nothing wrong with wanting things a particular way and the best apps/projects really do sweat the details.  The root of the problem is that non-devs *greatly* underestimate the time and effort involved in those details.  The important thing is to remember that everything is really just a function of time and money, a project that's over-spec'd at $1000 and 1 day is under-spec'd at $100k and 6 months and unfortunately if you don't have any dev experience (or frequently if you do) your time estimates are probably at least an order of magnitude too low.<br>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 4, 2014 at 10:57 AM, David Schwartz <span dir="ltr"><<a href="mailto:newsletters@thetoolwiz.com" target="_blank">newsletters@thetoolwiz.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It always amazes me that these discussions inevitably devolve into arguments about the tools.<br>
<br>
When people discuss new features for cars, like switching to hybrid or electic technology, do they spend most of their time talking about battery chemistry or the electromagnetic properties of different materials? Or do they talk about the benefits mostly?<br>


<br>
Why is it that we in the software world are so freaking attached to the technology used to IMPLEMENT our ideas?<br>
<br>
Way back when Windows 3 was released, I was doing my own consulting work for clients. I focused on real-time embedded solutions written in C/C++ that ran on DOS or some kind of embedded kernal.<br>
<br>
People kept asking me why I didn’t get into Windows programming.<br>
<br>
My explanation was simple: because I had observed that every time Microsoft came out with a new version of Windows, they required developers to attend a week-long training course in Seattle to become “certified”. It cost several thousand dollars and happened every 9-12 months.<br>


<br>
That in itself wasn’t so bad. The problem I noticed was that I knew a TON of small developers who did this a few times and ended up going bankrupt because of the long ramp-up time it took to absorb all of this new technology. What I saw was they’d pop for the training and certification course, come back home, start busily working on apps, and right about the time they’d be ready to release something, MS would come out with the Next Great API version and they had to start all over again!<br>


<br>
In the embedded design world, people much preferred stability — we used stuff that was solid and proved and stable and used for several years. Customers didn’t like new APIs, or even new programming tools.<br>
<br>
I see the same thing happening in the mobile world, except the market has been transformed such that virtually anybody can participate.<br>
<br>
In the iOS world, Objective-C is like C, only with quirks. C programmers can pick it up without too much trouble. Newbies don’t have to overcome their earlier biases and probably pick it up faster.<br>
<br>
In the Android world, Java is an old and stable platform,<br>
<br>
But in both cases, the mobile APIs keep moving! Apple releases a fairly massive update annually, and Google is doing their best to keep up with new Android releases.<br>
<br>
So you’re barely able to get up to speed with the latest API before a new one comes along and renders a lot of your work obsolete.<br>
<br>
To make matters worse, if you want to support multiple platforms, you need to be fairly proficient in SEVERAL DIFFERENT LANGUAGES AND PLATFORMS.<br>
<br>
Then from the marketing angle, you’ve got people who say, “Oh, HTML5 web apps are really the future, we’re not going to waste our time with native apps!” That’s all well and good, except it misses the point with native apps, which is that they’re able to access all of the hardware goodies that Apple and Android manufacturers keep adding to.<br>


<br>
That is, web apps will FOREVER be behind the technology curve when it comes to supporting the wizbang functions inherint in most mobile devices. Sure, they’re fine for generic data-driven needs, but not for things that are generating sales at the front-edge of the technology curve leveraging the latest hardware features.<br>


<br>
Now we’ve got a new language: Apple introduced Swift and is making it available for free, like their other tools. This is going to stimulate a whole new generation of devleopers to jump into the fray and start building apps for iOS — apps that are going to be hard to “port” over to Android platforms, or even web platforms.<br>


<br>
<br>
I’ve talked with Joe about his app. To his credit, he’s focused mainly on the app. But what he’s missed is the fact that, IMHO, he’s over-spec’ed it to the point where you'd need so much custom code to impement what appears to be a simple tool that he’ll never be happy with the end result. His UI design makes assumptions based on HIS experience with *nix shell scripting, and he clearly explains this in the spec. There are no native widgets that work like “grep” in the Android world!  So he’ll be extremely hard-pressed to find anybody who’ll build it for him within the budget he’s demanding.<br>


<br>
I’ve worked with something called Delphi since Borland introduced it in 1995. Starting with the XE2 release a few years back, they’ve been embracing a multi-platform targeting strategy where you can develop apps in one language that will run on any of the popular platforms: Windows, OS X, iOS, and Android. And it actually WORKS!<br>


<br>
You can’t even do that with JAVA!!! The supposed “write it once, run it anywhere!” platform.<br>
<br>
Again, I talked with Joe about his app, and there are no native widgets available in Delphi that implement the specific UI behaviors he’s looking for. I cannot build an app for him that fits his criteria as closely as he wants, but it’ll come close, AND it’ll run on all four major platforms.<br>


<br>
I’ve interviewed for a couple of mobile app jobs; I have a tough time getting interviews because they’re all looking for the same thing: 3+ years of experience with at least one app selling in either Google or Apple’s App Store.<br>


<br>
Who are they interviewing mostly?  Kids — gamers with no computer science background who’ve been building and selling games!<br>
<br>
Everybody else is spending so much time deliberating about whether it’s better to use Objective-C or Java or C++ or HTML5 or this platform or that platform, and will it fit into our strategic marketing initiatives in three years time …<br>


<br>
Sheesh … the only way to get a job doing mobile development these days is NOT so dependent on being a “mobile developer” but being able to converse intelligently about mobile languages and platforms. Because when Apple and Android issue an update, Marketing melts down and decides to stop development on everything while they figure out how to incorporate all of the latest cool new hardware features and API crap into their design.<br>


<br>
It’s the same as Microsoft’s Windows API update “tail" wagging the development “dog” all over again!<br>
<br>
Let’s talk about our customers for a change, and what we can do for them, eh?<br>
<br>
-David "The Tool Wiz" Schwartz<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Aug 4, 2014, at 9:48 AM, Paul Mooring <<a href="mailto:paul@getchef.com">paul@getchef.com</a>> wrote:<br>
<br>
> I wanted to send this to the list, because I think you make some excellent points here.  Also just for the record, I'm not necessarily saying I think do web apps for smart phones is better. I'm merely providing POV from someone working in the tech start-up space that that's what the industry is currently leaning towards.  I actually prefer native apps myself.<br>


><br>
><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">Paul Mooring<div>Operations Engineer</div><div>Chef</div></div>
</div>