Moving back to .NET

Ola Fosheim Grøstad via Digitalmars-d digitalmars-d at puremagic.com
Sun Sep 27 08:28:30 PDT 2015


On Sunday, 27 September 2015 at 10:38:39 UTC, cym13 wrote:
> You might like to read http://www.paulgraham.com/avg.html if 
> that's not already done.

Startups have a different logic to them, they might try to 
attract developers to build a small tight team, for less pay, by 
providing a more exciting cutting edge environment or might just 
aim to produce a proof of concept within their means/know-how 
with the goal of attracting investors... so whatever works for 
them.

But going with Lisp today in web development seems to represent a 
fairly high level of lockin. I wouldn't do it.

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

Calculated risk is one thing, unnecessary risk something else. If 
you are doing projects for external customers you really don't 
want to end up in a situation where they say "we want to port to 
platform X, we know that can be done in C++/Java" and then have 
to admit that you cannot do that with whatever non-standard 
language you pushed for.  Another issue is that you don't want to 
develop on 10 different platforms, so sticking with a good 
allrounder language platform is not a bad strategy for many 
development teams.

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

I don't really think choosing one of the more common modern 
algol-like languages over the less common ones affects your 
ability to produce the product. The software development process 
itself is more likely to play a significant role.

For software that is made for supporting organizations as much as 
80% of the total development costs might come after deployment. 
There are usually too many unknown factors in long term software 
development at the early project stages, so you cannot reduce the 
risks to the level you would like. What you can be pretty sure of 
is that requirements will change and that you need flexibility 
and the ability to evolve in new directions.

The department I was with, belonged to the scandinavian school 
within systems development which is largely looking at 
user-centered development where you involve/focus on real end 
users throughout the process. That is one way to reduce risk and 
increase acceptance among end users.



More information about the Digitalmars-d mailing list