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