and if you ask a boss or customer what is that
they prefer, pretty vs. working code, I can tell you that not 100 but
200% of them will choose working.I don’t give my clients that choice. They get properly designed code
that works. It’s not up to the client to make technical decisions.
I agree with this sooo much! However, if the client is large enough
it’s
very easy/tempting to just do as they ask…
Cheers,
Andy
Michael P. wrote:
- 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:
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.
On 3 June 2010 11:49, pepe [email protected] wrote:
if you ask a boss or customer what is that
they prefer, pretty vs. working code, I can tell you that not 100 but
200% of them will choose working.
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:
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 
Marnen Laibow-Koser wrote:
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.
On 03 Jun 2010, at 16:22, John I. wrote:
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?”
True, we all have to start somewhere.
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.
Best regards
Peter De Berdt
Peter De Berdt wrote:
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.
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?”
look at these sites (I did not make these!)
http://www.yvettesbridalformal.com/
really?!?
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.
Also have you checked out any flex groups? There should be tips there
too. This one is based in Dallas TX
http://groups.google.com/group/d-flexorg
Cheers,
John
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs
