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

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.

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.


On Mon, Aug 4, 2014 at 10:57 AM, David Schwartz <newsletters@thetoolwiz.com>
wrote:

> It always amazes me that these discussions inevitably devolve into
> arguments about the tools.
>
> 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?
>
> Why is it that we in the software world are so freaking attached to the
> technology used to IMPLEMENT our ideas?
>
> 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.
>
> People kept asking me why I didn’t get into Windows programming.
>
> 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.
>
> 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!
>
> 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.
>
> I see the same thing happening in the mobile world, except the market has
> been transformed such that virtually anybody can participate.
>
> 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.
>
> In the Android world, Java is an old and stable platform,
>
> 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.
>
> 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.
>
> To make matters worse, if you want to support multiple platforms, you need
> to be fairly proficient in SEVERAL DIFFERENT LANGUAGES AND PLATFORMS.
>
> 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.
>
> 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.
>
> 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.
>
>
> 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.
>
> 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!
>
> You can’t even do that with JAVA!!! The supposed “write it once, run it
> anywhere!” platform.
>
> 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.
>
> 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.
>
> Who are they interviewing mostly?  Kids — gamers with no computer science
> background who’ve been building and selling games!
>
> 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 …
>
> 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.
>
> It’s the same as Microsoft’s Windows API update “tail" wagging the
> development “dog” all over again!
>
> Let’s talk about our customers for a change, and what we can do for them,
> eh?
>
> -David "The Tool Wiz" Schwartz
>
>
>
> On Aug 4, 2014, at 9:48 AM, Paul Mooring <paul@getchef.com> wrote:
>
> > 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.
> >
> >
>
>


-- 
Paul Mooring
Operations Engineer
Chef