[clug] Think Pieces

jhock at iinet.net.au jhock at iinet.net.au
Sat Jul 10 01:58:52 UTC 2021

When I studied computing at uni, we would get a pass if the software worked and then a credit if the software was optimised, etcetera, etcetera. No one seems to do that nowadays. It seems to me that most software developers create something, do very little testing and wait for users to find the bugs. 

Often, if something doesn't work, I'm told "that browser is unsupported", I must use proprietary software or update my OS. This is the work, I my opinion, of people who should never be paid for their products. They are not software developers. 

I have noticed that nearly every single web page is invalid. How can anyone say that they have developed a web interface if the HTML is invalid? That's like saying "it's a car" when the wheels only turn going down hill. It's pathetic! All the developers have to do is validate their HTML and it's a disgrace that developers expect otherwise. 

This also applies to Android apps requiring Google Services Framework, etcetera. 

Anyway, that's my observation of current software developers.


On 9 July 2021 11:58:31 pm AEST, Brenton Ross via linux <linux at lists.samba.org> wrote:
>On Sun, 2021-06-27 at 18:09 +1000, steve jenkin via linux wrote:
>> ...
>> People and Teams come first, everything else falls into place around
>> that.
>> Managers, Deadlines, Deliverables / Customers / “Point of
>> Difference", detailed Project Plans with Critical Paths, Gantt Charts
>> and ‘output measures’ don’t improve code or hasten the work of great
>> programmers.
>> Yet they’re the staple of Commercial coding & design, where the focus
>> in on “The Process” not The Right Team & People.
>> ...
>Its called "binary thinking" - looking for the one thing that will
>solve your problems. In reality almost any of those things can doom a
>I suspect the reason we keep having this sort of discussion is that
>software development always seems to have an element of exploration and
>experimentation. The programs and libraries we incorporate into our
>designs don't always work as we expect - either because the library is
>different from its specification, or because we did not actually
>understand it.
>This inevitably leads to the estimates of how long a piece of software
>will take to develop being effectively random numbers. 
>The only time I was ever able to provide accurate estimates was on a
>project where we had access to the production system logs. When we
>noticed an issue we would quietly develop a solution. A few weeks later
>the change request would come through and we could provide a
>"retrospective" estimate. In effect we used a time machine.
>This "rubberiness" in the time to do things [throughout the entire
>process] makes software a very different management problem from other
>engineering disciplines. I once attended a presentation by a senior
>engineer for the company I was working for. The company culture was
>electronic equipment. He seemed to be under the impression that once
>the design for a program was done the rest of the process would proceed
>without any issues. For him, programming was an almost mechanical task
>of translating the design into some computer language. [I left that
>company fairly soon after that meeting.]
>From an organisation's point of view software is just something that
>needs to be created so some product can be got onto the market in a
>timely fashion within some predetermined budget.
>This puts our managers in a near impossible situation. They have a
>limited amount of resources, and some deadline that the company is
>depending on, and the whole thing can be put at risk by a single
>misplaced keystroke.
>Their response is to divide the work into a lot of small tasks in the
>hope that having a lot of small estimates will be a bit more accurate
>(it is). This set of tasks is, of course, "The Process".
>For an organisation that does many software projects this Process
>becomes the corporate memory of how to run the project. It evolves as
>things are learnt from project to project.
>However, even if you just recruited a heap of experienced developers
>and asked them to create some software I expect the first thing they
>would do is list out the tasks to be done - they would invent a process
>for the project.
>You need all of those things mentioned above:
>+ You need people with an aptitude for software development.
>+ You need managers that can assign the resources necessary.
>+ You need deadlines, deliverables, customers, "point of difference"
>otherwise there is no budget, and hence no project.
>+ You need to measure your progress so you can detect issues before
>they become problems.
>+ You need a process to measure your progress against and to ensure
>important tasks are not overlooked.

More information about the linux mailing list