On Saturday, 26 September 2015 at 11:00:39 UTC, Ola Fosheim
Grøstad wrote:
On Friday, 25 September 2015 at 21:03:12 UTC, Laeeth Isharc
wrote:
So, no, one can't say that in a blanket way risk aversion is
good project management if what you care about is enterprise
value rather than what people think of you.
Risk aversion is good software project management. Period.
What was it you were called by one compiler writer here ? The
king of shifting goal posts.
You don't argue in a straightforward manner, Ola. Your words
have a superficial logic to them, but not always much coherence
or common sense,
It is very common for software projects to not meet their
target and fail to adapt to changes in the environment,
Yes. One reason for failure to adapt is lack of plasticity and
ability to iterate rapidly. But there are many factors and you
can't reasonably portray it in the highly simplistic manner that
in my opinion you do.
so the
first thing you should do is mitigate risk for failure and
risks that you may not be able to move/change in the future.
No. The first thing you should do is think about what you want
to achieve and how you are going to get there. Then you can
think about what might go wrong, and what you will do if that
happens, and what sensible optionality and insurance you can buy
upfront.
You have to measure up the potential gains against potential
risks.
Now you are repeating my words to me with different emphasis
without acknowledging. If it's a question of balance and
tradeoffs then it's no longer purely about blanket risk aversion,
If the gains is 30% increased productivity and 30% higher risk
for failure... then you give up the increased productivity and
argue in favour of increased budgets.
If. And it's context dependent. But you're making assumptions
that may be true for you, and might be true for some others, but
won't be true for another group.
Most current imperative languages are more or less of the same
nature. They have different short-comings, but for
non-system-programming you can basically do the same project in
Go, C, C++, D, Java, C#, Nim, Rust, Ada...
Yeah yeah all Turing complete. But languages have many relevant
attributes beyond those, as Knuth pointed out in the speech I
posted an extract from here a while ago. The experience of
writing different kind of projects in those languages is not the
same, and in some cases that matters, sometimes a lot.
Programmers are human beings, and the work on ergonomics and
office design shows that even apparently trivial things can make
a great deal of difference to human productivity. And the
difference between writing in those languages is far from
trivial. The fact that you can do it doesn't mean the language
choice itself (setting aside tooling and libraries) is irrelevant
commercially, as you must surely at some level realize. The
right decision depends on the project and the context, and human
and organisational factors must be a good part of that.
BUT that is only the language. Production involves more than
the language. C++, Java and C# has a much larger set of options
than the other alternatives.
True, but whether this matters much depends on what you are
trying to do, particularly since with some effort you can talk to
C++ natively and more effort Java and prob C#. And if you are
building things in terms of micro services and the interface
doesn't need to be incredibly fast, then it doesn't need to be
native (and maybe sometimes shouldn't).
