Erroneous. You're not giving them all the information needed to make
their choice.
Sure, quick and dirty can have its place; but by using it you're
introducing Technical Debt [1], which in the long run can cost them an
awful lot more than had the code been written in a well-designed
fashion in the first place.
It's not a cut 'n dried choice between pretty and working (and trust
me, I've had to wade through ugly and broken enough times)... it's
much more complicated than that, and needs to be presented to decision
makers as such. The only way I use if people want a simple choice is
to say there are three options:
Ā Ā * quickly produced
Ā Ā * well written
Ā Ā * cheap price
... then give them an option to pick which two (and they can *only*
have two) of the three they want.
This makes it clear, that if they choose Quick and Cheap, they will
not be getting Good.
Returning to the technical debt argument; I've seen this in practice
many times. It's certainly frustrating when boss/customer ignores
sense and goes for short-term gain... but there is always the option
of working for other bosses/customers
* quickly produced
* well written
* cheap price
... then give them an option to pick which two (and they can *only*
have two) of the three they want.
This is close, but the most useful variable was left out of this list.
The choices are actually:
1. Time
2. Quality
3. Cost
4. Scope
Stakeholders are given their choice of three and development controls
the forth. I only mention this because scope is actually the most
"sensitive" of the four variables.
Quality is relatively ineffective at controlling the other three, yet at
the same time can profoundly affect the other three. In other words you
can't really "buy" time by lowering quality. Lowering quality in an
effort to reduce time will likely have the opposite effect. Code of poor
quality, in the long run, takes longer to write than quality code.
Time in many situations is fairly fixed. The product needs to ship
within some reasonable "budgeted" time scale. Hence time can also be an
ineffective control variable.
Cost is a somewhat tricky control variable. In some situations it can
effectively control the other three, but in other cases it is
essentially fixed, and as such can't be used reliably for controlling
the other three variables. Throwing more resources (programmers) at
project in trouble does not guarantee success.
Scope can often be the real key control variable for a large percentage
of projects. Scope can "buy" you time. Often building less (at first)
can deliver a working product, meeting or exceeding quality
requirements, within the budget of time and cost. This is the core
principal of agile software design methodologies. The feedback gained
from early, small, releases will also have a profound impact on all four
of these variables.
As I'm developing on Windows, remarks concerning Objective-C, Cocoa,
putting Cappuccino at the same sentence.. make me think this is not
the things for me right now even if I wanted to (wish it was)..
Then you completely misunderstood. Cappuccino is a JavaScript framework
inspired by Obj-C. There's nothing OS-specific in it AFAIK. Really,
take the initiative and do some research!
Precisely correct. Cappuccino/Obj-J was designed by and for Obj-C/Cocoa
developers to be as much like developing Cocoa-like applications that
run in a web browser on top of JavaScript. The only requirement is a web
browser that has a reasonably modern JavaScript engine. That pretty much
covers all current releases of web browsers on any and all platforms.
I really only mentioned it, because it's the choice I would make, and
that it does demonstrate the power and flexibility of the JavaScript
language.
Check out this demo to see just how "desktop-like" Cappuccino
applications really can be:
http://280slides.com/Editor/
Keep in mind that this application is entirely web standards compliant.
Not
sure about SproutCore.. I understand the pros and cons of using Flex/
Flash, though was nice to hear there are developers out there who do
use it (on windows), in case I do follow this direction...
After better understanding the suggestions, my tendency (or wish at
least) is to follow tools / technologies which will make my app more
likely to be accessible on most platform / following Standards-
compliant HTML..
I think that's a good choice. But that shouldn't be surprising.
I believe SproutCore is an excellent choice for most web developers. It
can still produce really desktop-like applications that run on top of
JavaScript, but still be somewhat friendly to web style development.
Whereas Cappuccino "feels" nothing like web application development.
The first "app" you wrote was it "perfect"? mine wasn't. We've all
gotten where we are from writing code and learning best practices.
Sometimes we have to just jump in and get it done. I don't like doing
that, but sometimes you have to. If all I did was read tutorials and
best practices, I'd never write any code. In three years we will look
at code and say "Why was this written in XHTML and not HTML5? What
were they thinking?"
Most people, read: non-programmers, don't care about the code. We do.
We care how it's created. Learning Rails, which means learning some
Ruby and OOP too, is quite a bit. Learning Flex on top of it is a lot
to chew, in my opinion. It can be done.
Again the Flexible Rails
Ā Ā Flex 3 on Rails 2
Ā Ā Flexible Rails
What it sounds like you're wanting to do is a good choice. it walks
you through of setting everything up. It uses Flex 3 and Rails 2. It
creates a "wonderful" to-do list. but you'll get the jist on how to
get Flex and Rails to talk to each other.
However, my first few projects, or should I say failed experiments, never went out to paying customers. Thereās no reason any customer should pay for the inexperience of the developer, whether thatās in short term (everything taking a lot more time than needed) or in the long term (plenty of obscure bugs due to no testing, bad code and no easy way to add functionality to the app in question).
My first few Rails projects were internal use apps, and yes, I learned a lot from them, but Iām very happy they never went outside of the company They are good for one thing though: when I do a seminar for students or beginning web developers, I like to pick out some examples from that old code to show how it SHOULDNāT be done
When I said database-backed web development is quite challenging, I was talking about the sheer number of languages and environments you have to feel comfortable with to produce a good product: database structures, a feel for good design, HTML, CSS, JavaScript, Ruby, Rails, OO programming. Bringing something like Flash into the equation replaces HTML, CSS and Javascript with Flash and ActionScript, but imo makes implementing the backend harder. I know Iām better off now and enjoy what Iām doing, but developing desktop applications was easier in many ways (and awfully annoying in other ways, but still), especially when it comes to one IDE with a GUI design environment etc. Whether Flash is a good way to go or not is up to the original poster, but unless heās very experienced with Flash (and I donāt mean the timeline, tweening and transforming objects etc) and especially ActionScript, I would seriously advise against it. It may be easy to throw together some Flex interface, but thereās still a lot to do behind the scenes thatās actually just as hard as going for a plugin-less solution.
However, my first few projects, or should I say failed experiments,
never went out to paying customers. There's no reason any customer
should pay for the inexperience of the developer, whether that's in
short term (everything taking a lot more time than needed) or in the
long term (plenty of obscure bugs due to no testing, bad code and no
easy way to add functionality to the app in question).
I don't entirely agree with this. Unless you're just creating
"cookie-cutter" style applications that can be completely predicted
up-front, the customer IS paying for the inexperience of the developer.
Nearly every application I've built in my long development career has
required learning something new, something I'm inexperienced with.
Whether that be related to the problem domain the software targets, or
the technologies required to produce the desired result.
As software developers we are as much researchers as we are developers.
Matching the right technologies to solve a problem is a major part of
what we do. Often the "right" technology is something we are not
currently familiar with. What distinguishes great developers is the
ability, and willingness, to take on new challenges, and new
technologies as they present themselves.
If learning a new technology is part of providing my customer with the
best fit solution, you bet I'm going to charge them for that.