roland at logikalsolutions.com
Sat Dec 22 18:05:51 CET 2018
I would like to thank everyone who has been mentioning "alone" as a
criteria in here. We all go through that stage and some of us never
leave it. Definitely going to make a nice essay in my new book.
At some point we all buy into the fantasy of one developer alone
creating something fantastic which makes them fabulously wealthy. On
rare occasions it even happens. The fact they don't get fabulously
wealthy until they hire others (at least from a business software
perspective) always seems to disappear from the story.
If alone is the singular criteria, perhaps one should consider DIBOL?
That system, which runs a complete credit union, savings, checking, CDs,
loan origination, etc., was created by one guy using DIBOL. It didn't
grow to become one of the largest, if not the largest, credit union
software package until he hired other developers. Why? People purchasing
software which will handle millions of dollars in transactions each
month weren't willing to be left twisting in the breeze if one guy got
hit by a bus.
I went through the alone stage too. Wrote a payroll system for a
trucking company by myself just because I wanted to try out a new tool.
That was the Pro-C generator back in the days of DOS. Heck, I even wrote
an electronic incometax filing system for a client who then licensed it
to numerous tax preparers once it passed IRS certification.
While the projects (far more than I probably remember now) brought in
money and made me feel good about myself, without exception, they were
stupid business decisions on the part of the customers. As soon as one
guy got hit by a bus or simply quit doing business with them (the case
of the tax system because the dude had a pension for never paying
invoices on-time or in full) they were left twisting in the breeze.
I don't remember if it was Demarco or Yordon who said in one of their books
"Your most indispensable developer isn't your greatest asset, they are
your greatest liability."
It doesn't matter whether it is QML, DBASE, Clipper, FoxPro or
insert-too-here someone believes is the greatest thing since sliced
bread and mouse traps, it's the lure of the lone wolf dream which draws
them in. The dream of income for life after only a few hours of work.
Personally and professionally I restrict my lone wolf activities to
writing my books and offering software for free from time to time. I can
no longer ethically justify lone wolf software development when I expect
companies to pay for it. If they want me to do everything on my own they
have to provide someone for knowledge transfer at the end. Just dumping
a bunch of source on them and saying "figure it out" isn't something I
can do to them anymore. Yeah, there was a time, but, not anymore. Not
for a long time. I've seen what happens when a business relies on a
single point of failure.
No matter how awesome and clean you believe your code to be, until the
support/replacement developer is able to review and understand all of
it, the code is neither awesome nor clean.
Here's a good example. Rsyslog, the system message logger used by most
Linux distros today.
When you scroll through the code on GitHub it looks pretty. Lots of
comments. Seems to be well formatted.
Try porting it to a non-Linux platform where the C compiler only goes up
to the first half of C99.
Try adding support for a new output message format for use when
transmitting to a non-Rsyslog collector.
That's when you find out how well you did. When someone else can
maintain it. You won't live forever, but a business using your software
just might. It definitely has the potential to outlive you.
Even when one watches this QML tutorial
It is easy to see how a significant UI developed with QML (or really
most of today's favorite tools) would lead to a pile of code an outsider
or auditor could read and validate the business logic behind. Something
Where little snippets of the logic would be scattered across hundreds of
QML files which pass stuff back and forth to C++ modules. I was at a
client site within the past few years where I didn't have to imagine
this. (No, I won't name them.) They tried to do every part of a control
system in QML and only in the places where QML failed did they pass
information back to C++ (and even C with __extreme__ use of macros).
Looking at the code you couldn't track input or output through the
system. Needless to say, developer turn over rate was high. The code
base had ballooned to ... I forget the actual module count, but it was
lots. I want to say over a thousand, but, don't remember an exact count.
Little snippets of business logic scattered everywhere. Adding or
changing logic could require close to a week if someone didn't tell you
which module to start searching in.
Even in the tutorial link above where clicking one thing updates a
counter in another. That would be business logic. Somewhere there would
be a BRD (Business Requirements Document) which stated clicking this
increments that. Ironically that client is a classic example of "lone
wolf." The guy with the idea, money and hardware knowledge hired one
developer. They went for a week's training in Qt but were pretty much
only taught QML. Dude came back and started banging out code without
__any__ thought to architecture. The AGILE mentality, when they want
something, throw a piece of code at it, trying to build a highly
involved system incrementally without an architected plan is like trying
to build the Sears Tower without one.
Just my 0.0002 cents and thanks again. When I finish kicking this
concept around, it will be a great essay. Should dovetail perfectly into
the essay titled "Too Big to AGILE."
Roland Hughes, President
More information about the Interest