On Sunday, 27 September 2015 at 09:51:42 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 26 September 2015 at 22:19:41 UTC, Laeeth Isharc
wrote:
[...]
I am not doing consulting on a forum, I am arguing against the
viewpoint that the lack of adoption of fringe tools is a result
of unjustified fear. I wouldn't make any blanket statement for
a business in any shape or form without talking with them to
understand their situation. I don't know why you think I am
doing consulting here.
But risk management is at the core of software engineering.
That is because there are many unknown factors during
development, but you have to set the trajectory at an early
stage, which includes picking the development environment.
Software process/methods maturity is often quantified in
"repeat success". That is, not that you have one success, but
keep repeating the success over many projects.
[...]
There is no prestige involved. But you seem to assume that
whatever holds for your field translates well to other fields.
That is most likely not true. If I started arguing about hedge
fund managment like you do about programming and engineering
you would most likely find it tiresome.
I've majored in human factors/software engineering, taught it
to students and been with a research group where many focused
on using Latour's actor network theory for understanding
organizations and systems development processes. Software
engineering is not a fun or easy topic to teach and also not
suitable for forum debates unless people have the same
background.
This is my key point: People are not avoiding fringe tools
because they are afraid of progress. Geeks are quite happy to
use fringe tools in their spare time or for smaller parts of
bigger projects.
Managers should avoid using unsupported fringe tools for larger
long running projects, for many reasons. The big players have
many more options, it means you are more likely able to move
and make changes later on in the project. Like adopting new
platforms such as ARM, asm.js etc. With a tool like D you have
to be prepared to take custody of the compiler/runtime to get
the same flexibility.
You pick a solution for a project, not a language.
You might like to read http://www.paulgraham.com/avg.html if
that's not already done. Of course risk must be reduced to a sane
minimum, but a project without any kind of risk is often a
project without value, sometimes taking a calculated risk to gain
a competitive advantage proves useful.
I see it a bit like software security (more my field): of course
security risk must be kept low, but not at the expense of the
ability for the company to produce its product. After all what
you're protecting is the ability for the company to make money.
