[Interest] Alone

Roland Hughes 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 
like this:


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
Logikal Solutions
(630) 205-1593


More information about the Interest mailing list