> 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 < rol...@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@qt-project.org > https://lists.qt-project.org/listinfo/interest >
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest