[LeapList]People w/IT careers:

[Steve Litt]

On Tuesday 28 January 2003 11:26 pm, Nick wrote:

[clip]

> However, I'm going to school
> for computer science, and it's kinda scary to see people asking for job=
s
> on leaplist (hire me too btw!:) and they have great experience, and man=
y
> of them degrees.=20

[clip]

Hi Nick,

One more thing. Right now, in my spare time, I'm working on a Rapid=20
Application Development Methodology that, if successful, will be useful f=
or=20
programmers building apps for small business.=20

Craig Davis and I discussed this very concept (we called it Linuxizing Or=
lando=20
back then) back in 1999. We both went on to other things, and I think Cra=
ig=20
actually did some apps for small businesses.

Up until now small business hasn't had custom apps because the cost was t=
oo=20
high. The cost was too high because most development methodologies, inclu=
ding=20
the revered Delphi, were much too slow. I think Clipper and Clarion were =
the=20
only 2 that got it right. I know little about Clipper (we'll let Phil dis=
cuss=20
that), but I know everything about Clarion.

Clarion was a template driven development environment producing data awar=
e=20
apps in a picklist->form->field->picklist... paradigm. These apps were=20
universally easy for users -- nobody ever got confused, and no help files=
=20
were necessary, assuming the app was well laid out.

With Clarion, you could create a working, useful prototype of a 5 table a=
pp in=20
one day. Forms, picklists and reports. Then, as the user wanted features =
or=20
application streamlining, you could easily code in those additions. Boy d=
o I=20
miss Clarion.

So I've been experimenting with Perl plus Perl Tk to produce the componen=
ts=20
necessary to do true RAD -- a 5 table app in a single day. I'm close to=20
having a Picklist object, and I now understand more about screen design w=
ith=20
the pack() layout manager, and may be able to create a screen design=20
jumpstarter. Reports are trivial -- Perl is perfect for all reporting,=20
assuming you're willing to live without cutesie fonts. And small business=
=20
owners are willing to live without that BS.

The way this would work is this: You make a deal with Joe SmallBusiness t=
o=20
*adapt* your software to his application needs. You still own your softwa=
re.=20
You can resell anything you make for him, although he has a right in=20
perpetuity to do anything he wants with your software except make it=20
proprietary. He can use you to further enhance it, or he can use someone=20
else. He has the source code.

You will not sign any non-disclosure, any more than an electrician he bri=
ngs=20
on the premisis would sign a non disclosure. If he wants niceties like th=
at,=20
he can pay $8000 instead of $400.

Yes, you flat amount him $400 for a working prototype, payable when you l=
eave=20
that day. You both understand that the prototype will allow him to punch =
all=20
data, but probably will not be optimally streamlined. As he finds specifi=
c=20
needs, you can fill those needs on an hourly basis, and because this soft=
ware=20
development methodology is so quick and adaptable, the hourly cost won't =
go=20
high.

One more thing, and this is sad. I'd imagine that 1/3 of the business own=
ers=20
will try to stiff you out of your money. Some will invent excuses why the=
=20
software isn't what you promised, some will endlessly repeat that they'll=
 pay=20
you "next week", and some will say "tough luck". Homer -- you're a small=20
business guy just like me -- am I overstating this?

You need to put a time bomb in your software. Make it 4 days out. If the =
check=20
clears, email him, tell him you made a little mistake, and tell him to=20
install the file attachment from the email in directory=20
/usr/local/bin/mycustomapp. That will difuse the timebomb without his eve=
r=20
knowing there's a timebomb. But if he doesn't pay, he's got 4 days of dat=
a=20
entry in there, and he's going to have to pay you before you lift a finge=
r.

Once again, before you show up initially, it should be agreed that at the=
 end=20
of the day, he gives you a check for $400 (or $600 when the economy gets=20
better). No net 15 or net 30 -- not on a $400 piece of software. TODAY. I=
f he=20
does that, and if the check clears, you'll disable the timebomb before he=
=20
ever knows you had one.

Excluding simulation, Orlando is horribly lacking in opportunities for=20
programmers. Over the long term, the only way most of us will make a dece=
nt=20
living in programming in Orlando is to market vertical apps to small=20
businesses -- the proverbial hotel software, video rental software, docto=
rs=20
office software, law office software. The only way to market those is to =
make=20
them 1/10 to 1/30 the price of normal custom software, and the only way t=
o do=20
that is a prototype driven rapid application development environment.

By the way, in his LEAP PHP presentation, Brian Ashe came incredibly clos=
e to=20
a useful RAD methodology. The only problem is that his screens depended o=
n a=20
web browser, and HTTP is stateless, and that complicates things to the po=
int=20
where it's not rapid anymore. If I could make my Perl Tk picklists the wa=
y=20
Brian Ashe made his PHP picklists, the job would be 90% done. Brian did a=
=20
beautiful job.

Even as we speak, there are Perl Tk discussions between myself and Perlme=
ister=20
John Simpson, and others, on LEAP's Pgrm101 mailing list. The resulting t=
ools=20
will be GPL, and AFAIK because they're in a scripting language, we can bu=
ild=20
a company's proprietary software with these tools. FAST.

See yall on Pgrm101.

SteveT