[Interest] Alone

Sat Dec 22 19:23:35 CET 2018

 > Personally and professionally I restrict my lone wolf activities to
writing my books and offering software for free from time to time.

Just out of interest: Do you have a link to an open source project of
yours?

Am Sa., 22. Dez. 2018 um 18:20 Uhr schrieb Roland Hughes <
roland at logikalsolutions.com>:

> 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?
>
> http://www.rcolmstead.com/rco.php
>
> 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.
>
> https://github.com/rsyslog/rsyslog
>
> 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
>
> https://www.youtube.com/watch?v=GkzncJ71mm0
>
> 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:
>
>
> https://cdn.shopify.com/s/files/1/1046/1086/products/ge-dash-4000-patient-monitor_386x386.jpg?v=1536280821
>
> 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
>
> http://www.theminimumyouneedtoknow.com
> http://www.infiniteexposure.net
> http://www.johnsmith-book.com
> http://www.logikalblog.com
> http://www.interestingauthors.com/blog
> http://lesedi.us
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20181222/97827434/attachment.html>