Moving back to .NET

[cym13 via Digitalmars-d]

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.