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

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.

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!

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

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

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

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

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.

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.

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!

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

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.