

Ask HN: Is it a mistake to base my company on the MSFT stack? - anonymois

I have been building two prototype versions of my software, one in C# (which I know like the back of my hand) and one in Scala (which I'm learning).<p>After spending time talking to a lot of developers, I'm concerned about continuing to use the Microsoft stack, even though I know it the best.<p>My concerns are:<p>1. Hiring. Will it be a problem to find excellent C# developers that are interested in working at a startup? So far I've found that the really great developers make huge salaries at Fortune 500 type companies and don't seem very risk tolerant. I think they're great engineers, but they seem way more interested in fishing than doing a startup.<p>2. Acquisitions: Pretending for a moment that I have a modicum of success, does choice of platform have an impact on the interest of an acquiring company? Will I be shooting myself in the foot by going the closed-source route?<p>I know that HN is mostly anti-Microsoft, but I think that people here are also pragmatic. Is it worth spending the time working with a technology that might not be known as well (although it seems to work well-enough so far) in order to mitigate the risks in hiring and acquisition later (if they are actually risks)?
======
e1ven
The biggest mistake, IMO, if you actually want to SHIP, is using anything
except the software you already know.

Let me explain- Too often, projects are started pie-in-the-sky, and using
everything perfectly, using the de jour framework.. You spend 80% of your
precious time trying to learn it, for marginal benefit. Yeah, it might be
cheaper when you have 1M users. Deal with it then.

For any software project, you'll probably need to expand a bit, that's a
given, but don't go out to far; Go one village over...

Try moving from MySQL to Postgres. Or perhaps involve Mongo if need be. Don't
fly in technology from the other side of the universe unless you have an
actual business need to.

The odds are against you finishing your project; Keep that in mind, and work
to maximize chances of shipping. This means using the stuff you know now.

------
jfdi
There's an old video of Steve Jobs circa 1997 where someone in the audience
puts him in the hot seat about some 'hot' technology at the time. As I recall,
his response was something along the lines of --- maybe we missed an
opportunity to use a neat technology in the product, but the product will win
in the long run because we remain focused on our customers, and work backwords
into the tech.

You can typically use whatever tech you want to power the thing. If you use
open and well documented communications API/infrastructure then others
(including your team) can extend your product with lots of different
technologies.

For #1 - You can find good C# coders. But you can find great developers who
know C# among other things.

For #2 - Generally there are two camps in acquisitions (strictly regarding
tech). The Microsoft camp, and the other camp. The two camps have their own
large ecosystems and there is some overlap. I think for this you just need to
understand (just like you understand your customers) which potential acquirers
may come along and what they care about. Many times they'll want to rewrite
some things anyway and better understand your roadmap (which can always
evolve!!!).

Long story short, stop building prototypes. Avoid optimizing prematurely as
they say. Get one prototype working well, get great developers and you'll make
the right tech decisions as a team. If you don't, you get to change them.

Good luck!

------
davidcrow
Check out BizSpark <http://bizspark.com> for a Microsoft marketing program
that gets startups access to the stack for zero upfront costs (yes that's
carefully worded).

Microsoft has a history of acquisitions, but they tend to be based on talent,
shared customers, market access or defensible technologies. Don Dodge covered
this a while ago
[http://dondodge.typepad.com/the_next_big_thing/2005/10/micro...](http://dondodge.typepad.com/the_next_big_thing/2005/10/microsoft_will_.html)

You bring up a good question about the risk tolerance of potential hires. No
opinion on it.

~~~
anonymois
I'm not worried about licensing costs at the moment, thanks to BizSpark.

My product isn't in an industry that Microsoft seems very interested in, nor
do I feel like it'd be wise to have the only potential acquirer be Microsoft
(which is why I made the point about being concerned about acquisitions).

------
burgerbrain
Building your company on a MSFT stack might be affordable when you are still
in the startup stage, and it might be doable when you're at the multi-national
stage, but in between it is going to be _expensive_.

On the other hand, developers for a MSFT stack tend to be pretty cheap.
Quality varies of course, but there are _lots_ of them..

------
maxdemarzi
Finding "excellent" people to work for any start-up is very hard. You already
know the C# is going to make it harder to find risk tolerant folks. People
working on Scala are most likely doing it because they WANT to, and would want
to do it at a start-up.

The acquisition question is business pre-optimization and any large acquirer
probably won't care. Just build your prototype and get it out the door, don't
worry too much about the details.

------
allwein
No mistake at all. I write iOS apps both for myself and as a contractor. All
of the web services that my apps run off are done in C# on Windows.

As many others mentioned, the best tool is the one you already have/know.

------
NY_Entrepreneur
Good question. You asked it, so now I don't have to!

The comments are good.

So, yes, for my startup, I'm using the Microsoft 'stack'. But for C#, I'm not
using it! Haven't touched it! Instead I'm using Visual Basic .NET and .NET,
ADO.NET, ASP.NET, Windows Server, etc.

For 'training' people, my guess is that 'basic' Visual Basic .NET will prove
to be super easy for nearly any reasonably talented, interested hire to learn.

Why? For nearly everything I'm doing, nearly all of the the syntax and
semantics of Visual Basic (the current .NET version) couldn't be easier to
read and type.

I also like the Visual Basic compiler, just as shipped with the .NET Framework
(version 4.0). The Visual Basic compiler is right there as file VBC.EXE, and
to run it just use a command line or some scripting language (I am using
ObjectRexx) to type the command line. The command line syntax is short and
easy to understand. The compiler is fast and generates remarkably small EXE
files. The error messages are from good to quite nice. So far I've found no
bugs at all. I'm thrilled.

My view is that the syntax of C# is more difficult, and so far I see no reason
to struggle with it. So, for my startup, so far it's just Visual Basic and
.NET.

For typing in software, I just use my favorite text editor KEdit with a lot of
macros. And I make heavy use of just the ordinary desktop 'windowing': So,
when typing, typically I have about 15 windows open, 'tiled' with the upper
left corners running from upper right to lower left (can always see at least
the top or left side of each window and can rearrange the Z-order without
moving any windows). So, I have windows with pieces of my design, software,
testing, documentation, etc. all readily available. It's nice.

I'm also thrilled with how ASP.NET works when I just type in Web page software
with KEdit. So, when a browser displays a page under development, if there are
Visual Basic errors then get a nice page in the browser making clear what the
errors are. NICE. When the compiler errors are gone, then at the bottom of the
Web page is a NICE description of all the work ASP.NET did with a 'control
tree', various ID values, some sizes in bytes, some timings in milliseconds,
etc. NICE.

When finally understand from 5000 feet up basically what ASP.NET is doing,
then it's fairly simple and clear and okay.

Why I am staying with Microsoft:

(1) What I Knew. I got started on that path to Microsoft and stayed on it. So
I did a lot with OS/2, and when I changed to Windows it was, of course,
similar.

(2) Documentation. I am finding that my code is heavily just some 'glue' to
call code from Microsoft, especially their .NET. So, I do more reading
documentation than writing code. So, I care a lot about the quality of the
documentation.

The Microsoft .NET documentation is enormous. I have about 2400 Web pages of
Microsoft documentation on my computer, abstracted, and indexed, and I put as
comments in my code the file system tree names of relevant documentation and
with one keystroke KEdit will display the Web page. Nice.

But that's a LOT of documentation. Writing such documentation is EXPENSIVE. In
simple terms, the quality from Microsoft is high. More deeply, often the
writing quality of the real 'content' needs to be improved. I'm afraid that,
without the big bucks of Microsoft, alternative documentation would be worse.

(3) Support. If my startup is successful, then I will want a lot of technical
support. I'll be willing and able to pay for the support. I am hoping that
going with Microsoft I will be able to get some good support.

So far I've gotten some surprisingly good support for free from various
experts at Microsoft via various Microsoft fora. Of course, to get a good
response, tend to need to have done some good homework and actually ask a good
question! The free support is so good that I am looking forward to some nice
help when I'm able to pay.

For Unix flavors, I'd be afraid on each of these three points. Afraid? Yes.
Well informed on Unix? No!

~~~
runjake
Your comments are interesting, as VB and VB.NET are distinct languages with
differing (though similar) syntax and quite different paradigms.

VB.NET shares its paradigm more with C# than the classic VB. VB.NET code can
be ported cleanly to C#.

~~~
NY_Entrepreneur
Yes. On the 'porting', I can believe that! However, I couldn't do the porting
because I don't know C# syntax!

For "classic VB", I don't know that either! I never used it. For Windows
programming, I just started with what you call 'VB.NET'. I didn't mention
'classic VB' (or VB 6.0 or whatever it was) but tried to indicate that I am
using the newer, most recent version of VB and am also heavily using .NET,
ASP.NET, and ADO.NET.

On the 'porting', sure: It appears that in effect Microsoft went 'language
syntax agnostic', concentrated on the lower levels down toward the processors
and Microsoft's 'common language runtime' (CLR), their 'intermediate language'
or whatever they call it, etc. and in effect said that anyone was welcome to
develop any 'syntactic sugar' on top they wanted. Sounds like a good move to
me.

I understand that C# offers a little that VB.NET does not, e.g., for
'reflection' or whatever, useful for writing polymorphic or more efficient
late binding code. Okay. I'm trying to avoid using late binding. For
polymorphic code, mostly for object oriented programming, I'm just using .NET
where I mostly don't have to think about polymorphism.

I have written a few classes and, then, a few polymorphic functions, but there
I used interfaces which I regard as much the same I've done for decades with
'entry variables'. The problem has always been, and still is, inside the
polymorphic code, for each time touch the relevant data, have to call a
function that is passed to the polymorphic code, and even just a little such
usage can double or triple execution time of the polymorphic code. Of course
another way out is to use 'generics', but those go way back, also: Basically
just have the compiler write different versions of the code depending on the
data types to be used.

Since VB.NET can be translated to C#, if I have to look at some C#, then I
will imagine that I'm just looking at VB.NET with some 1-1 syntactic
translations.

But the thread was concerned about training employees, and it seems to me that
the syntax, semantics, etc. of VB.NET are so nice that, just for the language,
the training should be fairly easy.

Moreover, in my work, nearly all the effort is just understanding the
documentation for .NET, ASP.NET, and ADO.NET. Then that understanding should
be quite similar no matter what language is used to get to .NET, etc.

For understanding the basic VB.NET syntax and semantics themselves, that's
from easy down to nearly trivial. So, for my company, I'm trying to stay with
VB.NET instead of C#: Get what my company needs, have the code easier to read,
and have training easier.

Yes, one of the nicer parts of VB.NET, and likely all the languages based on
the CLR, and maybe not so easy for a beginner trying to understand and use, is
the CLR 'garbage collection' (GC). I was afraid that maybe each few seconds GC
would wake up, put all the application logic on hold, do its GC, and then
restart the application logic, but so far I've been pleased: From some timings
I've done, etc., I've seen no significant such intervals of 'application logic
on hold'. What will happen with VB.NET and GC on processors with many cores
will be interesting to watch.

I don't know that the CLR, VB.NET, C#, the other Microsoft languages based on
the CLR, and .NET are in all ways the best possible, but so far I'm pleased
and thrilled. E.g., they look solid enough for me to concentrate on my work
for my company.

I've seen a lot in computing, including IBM's old efforts at some
'commonality' in the programming languages, etc., saw a lot of messes, and see
what Microsoft has done as much better. That they got GC working well is
IMPRESSIVE -- they could have messed that up. Microsoft could have made a huge
mess out of the CLR, etc., but it appears so far that, instead, they did some
good work.

What's comparable or good/bad in the Unix/Linux world I don't know.

