[clug] Think Pieces

[Brenton Ross]

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
project.

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.

Summary
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.

Brenton