On 7/15/20 5:00 AM, Cristián Maureira-Fredes wrote:
I'm pretty sure you understand how your message breaks our Code of
Conduct, and making those generalized bias comments about developers
using other programming languages from different countries
is not admitted in this mailing list.
I'm certain The Qt project has many people that come from different
backgrounds, and not because they didn't have "a formal CS education"
means that they will produce bad code or harm any project
You can find JavaScript people for absolutely no money. Simply look at
sites like UpWork and see what they bid to do projects.
Not having a formal education is actually a yardstick for measuring
potential quality of work. That is why you see "B.S. in Computer Science
or related technology" on soooo many job postings. To do really good
work, or at least avoid tragedy, you need a solid grounding in the
fundamentals. Reading one language specific book and hanging out a
shingle then working on AGILE projects without The Four Holy Documents
written up front really does mean they are going to produce bad
solutions if not "bad code" and harm the project.
When a human goes from infancy to adulthood, along the way they are
taught not to play with matches, the meaning of hot, especially around a
stove and other basic fundamentals of navigating life. Without being
taught these fundamentals we get burned badly and sometimes perish. A
formal CS education provides an infant developer that transitional
knowledge to "young adulthood." It teaches them many fundamentals to
avoid getting burned and having their career perish.
When working with actual Software Engineering one can get by with only
knowing only syntax and having the ability to read. Software Engineering
requires The Four Holy Documents be created up front. All significant
design decisions are made for you, "simply" code and test them. (Yes, it
is not always simple or fast but you don't have to do a lot of deep
thought.)
Here's a real life example for you which should paint the picture
perfectly. This happened with an all on-shore team too. All either
self-taught or having gone to non-rigorous schools, also called diploma
mills in the states.
The product the company was making was a livestock barn monitoring and
control system. All fans, curtains, misters, feed augers, waterers,
lights, heaters, etc. 24/7 monitoring and control without being there.
The team tried to do much/most/far too much of said system in JavaScript
and QML. At the core of this system were many sensors for temperature,
light, feed and water levels, even working on a methane sensor I believe.
Said product got installed in a barn that was soon filled with freshly
weened young livestock. Seemed to work well for about two days then in
the middle of the night it, via the watchdog, when into a perpetual
reboot cycle, exercising the equipment for roughly seven seconds before
entering another reboot cycle. Roughly 14 hours and an unknown (to me)
number of dead animals, the storage SD card was replaced "because it
must have went bad." The system believed it was write protected.
This happened again a few days later; and again. I joined the project
roughly at the time this started.
Remember the sensors? The self-taught team stored their readings in a
directory tree by sensor type, one JSON file for each sensor. Many of
the sensors had 5 readings per second coming back. Each reading required
the JSON file to be read, data appended, and file rewritten. It took
roughly two days for the file to get large enough that it could not
complete being written to "disk" before it had to be read for data
storage again. This caused a series of error flags in the disk device
driver which well and truly believed it had a disk in trouble at the
other end of the connection and put it into write-protect mode to save
it from further harm. Failed writes in turn triggered the watchdog which
attempted to correct things via reboot.
Neither the disk driver or the watchdog were at fault. They did exactly
the jobs they were designed to do. They simply couldn't fix a design
error brought about by lack of both formal training and The Four Holy
Documents. Had someone with formal training been involved at the
beginning JSON would have never been chosen. No file storage method with
an ever increasing write time would have ever been chosen. Even if the
I/O could have happened fast enough, the SD card was way larger than
physical RAM and there were multiple sensors with that reading speed.
The files would have gotten too large to fit into RAM, especially
multiples of them being processed by multiple threads.
Formally trained individuals would have reached instinctively for a
relational database, an indexed file, or even a sequential file, where
the application could always just write the new record and go. Peer
review never brought this up. By the time I was brought in there were
thousands of lines of code built around this tree of JSON files and it
was integral to the system. It all had to be gutted to put in database
support. Took way more than a sprint (a month really). Was ugly because
many other changes were happening at the same time.
It is true that when Software Engineering is used, creating The Four
Holy Documents up front, a project can use developers who are incredibly
green first timers that really only know some language syntax. That's
one of the reasons the documents are created. Those developers cannot
get into real trouble because all code is reviewed against the
documents, especially the System Architecture Document. They can't just
add something to the project because it is neat or cool to them. They
are also required to participate in the meetings and creation of said
documents so they learn the processes and the "why" behind each of them.
When you take green first/few timers without formal training and toss
them into an AGILE shop that doesn't create The Four Holy Documents up
front, there are no guard rails on the mountain roads. Projects go over
the edge.
--
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
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
