Ask Slashdot: Best Practices For Starting and Running a Software Shop?

An anonymous reader writes: I'm a systems architect (and a former Unix sysadmin) with many years of experience on the infrastructure side of things. I have a masters in CS but not enough practical exposure to professional software development. I'd like to start my own software product line and I'd like to avoid outsourcing as much as I can. I'm seeking advice on what you think are the best practices for running a software shop and/or good blogs/books on the subject.

To be clear, I am not asking about what are the best programming practices or the merits of agile vs waterfall. Rather I am asking more about how to best run the shop as a whole. For example, how important is it to have coding standards and how much standardization is necessary for a small business? What are the pros and cons of allowing different tools and/or languages? What should the ratio of senior programmers to intermediate and junior programmers be and how should they work with each other so that nobody is bored and everyone learns something? Thanks for your help.

Comments

First and foremost

[vivaoporto]

Get a good accountant to keep the books in order. Get a good lawyer so you always have someone vetting your contracts and preventing or solving any litigation you may find yourself entangled.

Don't try to do all by yourself, delegate everything you are not a specialist so you can focus on your core aptitudes.

Re:First and foremost

[Nuitari The Wiz]

Also look at oursources payroll, time tracking (this is sometimes a must for R&D tax credit) and make sure you have some financing / funding lined up. You need to have a plan to cover the first 2 years of operations where revenue will be slim.
This will also allow you to avoid getting into the "anything for a buck" mentality.

Don't focus on development tools / standards. Let your programmers take care of that. You might want to look for a lead developer with experience managing junior / intermediate developers.

Re:First and foremost

[Aighearach]

The problem with that is that it leaves him hiring somebody to run his business, somebody to develop the product, somebody to manage the financials, everything. Having a Masters degree means you're qualified to be a jr-level teacher, or an entry-level employee. The fact is that if he's going to be "running" a software shop, he's going to be doing a whole bunch of things he isn't qualified for or experienced with.

The real answer is, don't try to do that. It puts the cart in front of the horse.

The first thing you need to do if you want to go that route is to become a Software Consultant. Gain some experience running a 1 person software shop where you're writing code that others need. Once you have a few years of experience at that, you'll be in a position to start asking about how to set up a software shop and make your own products.

Try to understand that the degree is only useful if you want to be a teacher. Any other value from your education is what you learned; and it is a lot less, to be honest, than you'll be expected to be learning in the field from year to year on your own.

Re: First and foremost

[American AC in Paris]

Even before that: have a business plan. Do your best to determine what you want to create, how expensive it will be to make it, how many people you'll need to manage, how much you expect to charge for it, and how big your likely market is. If you discover that there's no way to make your endeavor even close to profitable, you can save yourself months of heartache and mountains of lost money. Always have a plan, even if you don't stick to it in the end.

Re: First and foremost

[Anonymous Coward]

Get an actual customer first. An accountant and lawyer are a waste if you're not actually conducting business.

Re:First and foremost

[rtb61]

You missed, avoid outsourcing your core service because of course you are not just giving you ideas away for free (there of course is nothing FOSS wrong with that) but you are paying people to take them and directly funding potential competitors. Outsourcing was just bean counter spreadsheet bullshit to grab the bonuses in the short term at the expense of crippling long term survivability. All those years of developing your companies skill set are gone, evaporated in the blazing sun of short term greed and instead you have just funded the development of skill sets of other companies.

Keep in mind the top level of outsourcers only outsource things like management because it gives them the opportunity to hugely inflate management costs, shift them to offshore tax haves and not only cheat on taxes but also to hugely cheat their own investors, whilst spreading lots of PR fertiliser about saving money.

Of course when it comes to software/web development the first thing you need to decide is whether you want to create a real long term company or just create a scam that looks good and gives something 'investment' companies can promote and sell to the gullibly greedy before it all 'mySpaces'.

Re:First and foremost

[JWSmythe]

I was going to say something like that, but not as well. I've been in interviews where someone is asked about their experience.

"What experience do you have?"

"I spent 6 years at [university] earning my Masters degree."

"Ok, what *work* experience do you have?"

"I worked for 6 years earning my Masters degree."

"Lets try this again. Have you ever been employed and paid for work in this field?"

"We had projects at [university] where we worked on various projects to earn my Masters degree."

I'm not saying that the original post is that kind of person. He says he worked in IT infrastructure for years. I would think he would have been exposed to the development side, at least a little bit.

Unfortunately, with the questions asked, I suspect it may be more like my example above. If he had the necessary experience, he'd already know, as the owner of whatever new company he's starting, the lead dev is going to provide the best answers to those questions. The lead dev is going to have their own opinions and methods that everyone on their team is going to work with. Unless he's going to do the CEO/CTO/CIO/lead dev rolls all at the same time, which isn't going to work as well as he'd hope.

Re: First and foremost

[toonces33]

The Payroll/HR stuff can be contracted out - especially if you don't need a full time person to do the job. Our neighbor works as a consultant providing exactly these types of services. If you become successful, and you grow then you can hire a fulltime HR/Payroll person..

That makes it easier to focus on your core functions.

Re:First and foremost

[i.r.id10t]

"Lets try this again. Have you ever been employed and paid for work in this field?"

Why is a pay check important? Having a portfolio of work, be it class projects, contributions to an open source project, perhaps having a patent granted, etc. should count just as much as earning a pay check for a few years working as an assistant code monkey to the junior developer of some corporate sub-project.

Re: First and foremost

[drooling-dog]

It's always a good idea to have a rough map of where you think you're going, but be careful about getting too carried away with formal business plans. You'll meet lots of people educated in business who will tell you that you need to sweat blood over a comprehensive plan - to the neglect of everything else - and then tour the country with a finely polished road show pitching it to potential investors. They tell you this because it shines the spotlight on their own training and talents. In reality, successful software business development almost never works this way, unless you have a stellar track record with several big hits behind you already (in which case they're investing more in you than the specifics of your plan). As others here have pointed out, what matters most is your rapidly growing list of happy, paying customers. Don't let your focus get diverted too far from that.

Re:First and foremost

[Euler]

Paid job experience can be very narrow and misleading as an indicator of future success in another technical job role. You can spend decades coding the same paradigms that happen to fit your employer's specific industry. Worse, you may fall into specific patterns and jargon specific to one particular employer. Formal education is specifically designed to handle a broader range of problem solving and knowledge; and it proves a candidate's basic work ethic.

Job experience helps to temper idealistic expectations to better understand what customers will pay for and how to deliver that effectively.

So I guess it depends what the job role is specifically.

Re:First and foremost

[Anonymous Coward]

Oh please. Have you seen academic coding projects? Even worse, have you seen academic coding projects written by a single person?

It's almost always completely unmaintainable slop, and probably not even version controlled.

Unless someone with zero employment experience showed up at my door with a tidy, maintainable, useful academic project with version control and a nontrivial test suite, I would treat that applicant just like GP insinuated.

Typically, the insight an applicant with an academic background is missing is that it is far more important for code to be clear and maintainable than it is to be clever.

Re: First and foremost

[AchilleTalon]

It seems you didn't get it right. Before getting a customer you need a product. Before getting a product, you need to develop it. To develop it, you need people and to get them you need to pay them. You then need an accountant, a lawyer and some of the basics to run a business. You cannot wait until you are ready to sell a product developed over a two year period to hire/contract an accountant. You need to start it right on day one.

Re: First and foremost

[beaverdownunder]

If you create the product yourself you don't need an accountant until you sell it.

Re:First and foremost

[datavirtue]

Yep, I'm running into people who are being hired as architects and they know barely anything because they have been stuck working on the same crap for ten years. I worked on my own outside of corp America for ten years always doing what I wanted to do, experimenting, making mistakes on my own stuff. I learned a lot....a lot more than I thought I had as I'm now employed to examine software systems that have been designed by senior developers and architects--fixing thier crap systems and documenting their blatant mistakes.

I'm also finding that they are using the business to experiment and pad their resume most of the time which is not tuning out good. They have attempted to build systems that are scalable and robust--ending up with products that are neither and worse than the simple solutions they replaced. In every meeting and design session I'm in I hear "I have never done X before (replace X with any fad or buzz tech you can imagine) but it is the way it should be done." I let loose with questions and insights and all I get is stammering and blank stares. It is a joke....and the company is trusting them to build key systems. So far it has not gone well.

Re:First and foremost

[datavirtue]

There is no such thing as cheating on taxes. If you can avoid taxes in any way then by all means avoid them. If it cannot be enforced then it was not meant to be.

Re:First and foremost

[kefalonia]

Or, better, find an agent who can act on your behalf and provide for both, against some reasonable cost.
There is no reason to reinvent the wheel, unless you really need to.

Re:First and foremost

[Anonymous Coward]

"Lets try this again. Have you ever been employed and paid for work in this field?"

Why is a pay check important? Having a portfolio of work, be it class projects, contributions to an open source project, perhaps having a patent granted, etc. should count just as much as earning a pay check for a few years working as an assistant code monkey to the junior developer of some corporate sub-project.

Sadly potential employers do not value portfolios of unpaid projects. I would be shocked if Linus Torvalds could get paid employment today had he just created Linux 0.99 yesterday. Today employers are short-sighted bastards licking their own genitalia as a reward for not hiring anyone and training them on their processes and development environment.

Re:First and foremost

[Anonymous Coward]

The general attitudes of "This is how things are done" or "It's done right because we haven't been doing it wrong all these years" are very common in both industry and academia, in the face of evidence to the contrary, or even outright past and recent failure.

Re:First and foremost

[gatkinso]

A graduate project is not nearly as fluid as a paying gig. It is agreed up front at the start of the project and generally this is what is produced. Not so in the real world.

Then, your work is graded. Maybe not the best thing for your academic career, but in many cases you can take a C and move on. I business this is called "failing" and this means all of a sudden you and your employees have nothing to eat and all the lights turn off in your house.

There are no advisers. There are no facilities or resources available to you save for what you can provide for yourself. The deadline can abruptly change due to funding and competition (along with 1000 other reasons).

These are just some of the reasons why academic work is not a great measure of real world experience. Mind you I am not saying acedemic work is useless, but I definitely differentiate between the two.

Re:First and foremost

[Hognoxious]

Having a Masters degree means you're qualified to be a jr-level teacher, or an entry-level employee.

Speak for yourself. We don't all come from some place where you get a Bachelor's from the back of a cereal box.

Re:First and foremost

[unrtst]

Why is a pay check important? Having a portfolio of work, be it class projects, contributions to an open source project, perhaps having a patent granted, etc. should count just as much as earning a pay check for a few years working as an assistant code monkey to the junior developer of some corporate sub-project.

While I agree with the other replies to your comment (ie. it is quite different and very important), none of them seem to mention the grey area here where you are right. That is, having a portfolio of unpaid work can be plenty in order to get a low to mid level developer job.

However, the question was about a lead developer position. At that level, you can disregard the "developer" part in order to answer this question as it applies to practically all professions. It doesn't matter how awesome you are at the core task (translating ideas into code that works) if you have zero experience with all the other duties that make up a head/chief/lead position.

This also goes the other direction. An applicant could have years of experience being a very effective manager in another field but, if they do not have any development experience, they shouldn't get the lead developer position. The position bridges two areas of expertise and requires experience in both.

The dual role has one relaxed restriction - you do not need to be the hottest code monkey there is, nor do you need to be a six sigma black belt. You do need to understand both and how to communicate across the domains.

Re:First and foremost

[tnk1]

Not true. We hire people out of college all the time and value their work to some degree. We just don't make them lead developer on hire.

You need a few things to be a senior developer. Having CS skills and training is obviously a big part of it, but being able to deal with other people, understanding the tools we use, and understanding the bottom line in business are just as important.

A Master's degree helps to the extent that you used that time to train yourself up on things that would be useful in your future career. However, it is very possible that all that work on your thesis and in seminars is only going to directly assist you if you walk right into a company that does what you were researching. If you are working on 3D graphics and you go to work for a company that does accounting software, you've probably learned useful things, but you have a lot to learn about what you will be doing in your job.

Hell, every time I switch jobs it seems like I alternate git and svn. The same goes with build software, libraries, etc. Most of the skills you end up using, you'll have gained on the job, not in school.

Re:First and foremost

[g4sy]

hahahahahahahahaha nope. not even close. here's a hint: would you tell you younger brother to spend 4 years doing those "projects" or 4 years solving problems for the real world and a couple hours doing open source problem solving at night? yah, i thought so. if you say you picked the former, you're lying. or don't have a younger brother. source: been in industry for 15 years, running business in london for 3 years now.

Re:First and foremost

[rtb61]

You are logically required to contribute to the society that promotes your opportunities for 'income'. Failure to do so, means that you are parasitism on those who do and just like all parasites, you should be targeted, and eliminated. The greater the parasitic impact the greater the penalty, get past a million and loss of all profits during that period, past a hundred million and destruction of company is sensible because of the extreme damage done to the country by theft of social, security and infrastructure services. Do not pay for these and your are a liar, cheat and a theft and when it comes excessive the early death of many of that countries citizens due to loss of services. Now that is the harsh reality of psychopathic ring wing capitalism. User pays, they benefited by the provision of an economy by others, generated a profit and cheated on paying access rights to that economy and stole those services that provide and support that economy which generate the opportunity for revenue and profit.

Re:First and foremost

[YrWrstNtmr]

Why is a pay check important?

Eating is kind of important.

Re:First and foremost

[Euler]

Fortunately, most academic projects don't need to be maintained beyond the semester, much less from one week to the next. It might be a good topic for freshman to learn to use version control, but that would be a relatively small part of what someone goes to school to learn.

Re:First and foremost

[Euler]

So true. It takes a lot of patience because it will be like that at a lot of jobs and you don't want to piss off the wrong people.

Sorry, you'll have to outsource.

[BarbaraHudson]

I have a masters in CS but not enough practical exposure to professional software development. I'd like to start my own software product line and I'd like to avoid outsourcing as much as I can.

Since you're getting into something you by your own admission lack domain experience in, unless you've won the Powerball and have a lot more money than brains, anyone you interview will realize that you're going nowhere and hence even the short-term prospects are, at best, poor.

At least with outsourcing, you can BS them as much as they BS you so they won't walk out the door shaking their head.

Bonne chance, 'cuz you're gonna need it.

Re:Sorry, you'll have to outsource.

[BarbaraHudson]

You could just google for it

Re:Sorry, you'll have to outsource.

[umdesch4]

[citation needed] Specifically I'm saying, citation of someone with no domain experience in a type of business starting one, and becoming wildly successful that wasn't due to either luck or downright unethical practices. One example please...just one. Thanks.

Re:Sorry, you'll have to outsource.

[BarbaraHudson]

They said that to Mark Zuckerberg also.

Zuckerberg had two things this one doesn't - a product and users.

Re:Sorry, you'll have to outsource.

[cold fjord]

Since you're getting into something you by your own admission lack domain experience in, unless you've won the Powerball and have a lot more money than brains, anyone you interview will realize that you're going nowhere and hence even the short-term prospects are, at best, poor.

At least with outsourcing, you can BS them as much as they BS you so they won't walk out the door shaking their head.

So in short you didn't really have any useful advice, just spite, that for some reason some people think is "insightful."

Re:Sorry, you'll have to outsource.

[BarbaraHudson]

So you don't agree that someone should be dissuaded from blowing their brains out on starting a software shop when they have no domain experience?

His position is the same as someone posting "I've delivered fresh fruit and veggies to restaurants for years. While I have no actual experience running a restaurant, I want to start one. What do you suggest for cutlery, seating, and wine lists?" No info about the type of clientele he wants to cater to (same as the poster) or the type of product he's planning on serving (same as the poster), or even a provisional budget or location (same as the poster).

All these are more important in making an informed decision, and will shape the answers to the questions he's actually asking, such as staff ratios, tools, etc. And they're ALL missing. The fact that they're all missing doesn't bode well. This is why we have "Ask Slashdot." If he wants to post the answers to type of clientele, product/service, budget and location, then maybe the responses would be different.

For example, if he or she DID win $50 million in a lottery, the first advice would be "don't blow it on building a software house." Second advice would be "If you really insist, set a maximum budget and if it doesn't make it, be merciless and pull the plug. And hire someone who knows their stuff and is cynical as all heck - having yes-men around you will cost you in both the short and long term."

Re:Sorry, you'll have to outsource.

[Hognoxious]

On Facebook, those are two names for the same thing.

Re:Sorry, you'll have to outsource.

[Hognoxious]

Surely what he needs is the "opposite half" of himself - a great developer who is bad at (or just hates doing) the things OP is good at?

Now whether such a person would be willing to take the risk on an employer with no track record is another question. Possibly, if one had a row with the boss over a fundamental point like whether a utilikilt constitutes business attire or where the { and } should go; but I reckon he might be more likely to find one as a partner.

Re:Sorry, you'll have to outsource.

[BarbaraHudson]

Sorry, that wasn't my intention. The poster had asked a question, so I just posted the first site that came up on google, which just happens to do a good job of answering it, pictures and all.

If you scroll to the bottom of the page (the "after" pictures), you'll have to admit that the end results are pretty good - and btw, fully functional in *all* respects in most cases :-)

Outsource

[prefec2]

When you setup up accountancy and have a lawyer, you can create a development team. Depending on your domains, expertise, and scale you want to enlist people for domain analysis, requirements engineering, software design, programming, UI design, etc. As it is too expensive to hire so many people, it might be best to outsource that to freelancers. Therefore, you need an appointment with your lawyer to draft the necessary contracts.

Re:Outsource

[wlj]

This is the best high-level advice I have seen so far in this list: business infrastructure FIRST!

Don't forget, that includes a "business model" (basically, what do you plan to offer and how will you make money in the process of delivering it) plus "customers" (you know, the people that pay for what you plan to offer).

Good ideas are important, but a business really needs the model and customers. Otherwise, it is called a "hobby".

Good luck. :-)
 

Write software

[pbjones]

As if you are the one who maintains it.

Re:Write software

[Aighearach]

Write software as if you are the one who maintains it.

... and lacking experience and having only some letters next to your name... you will be the one who maintains it!

Re:Write software

[Frankie70]

So just make sure you will understand it. Others need not.

Get a sales force and some customers

[Kohath]

Business is about sales and customers. Everything else you do is completely irrelevant if you don't have sales and customers. If you don't have a good plan to sell your wares, you don't need to spend 5 minutes thinking about how you will produce them.

Re:Get a sales force and some customers

[Anonymous Coward]

Google is well known for its salesforce and how they made Google such a success. Also it's marketing. That was sarcasm for those that can't tell.

Based on your question, the correct answer for you is to go get a job at a large company and work your way up to middle management.

The techie way to start a company is to have a vision and follow it no matter what. You do so in the most expedient manner possible. Worrying about waterfall vs agile is like buying a Oracle HR system for your 3 man company.

The sales way to start a company is to identify one or more clients with a problem and basically sell to them before you even start. You usually start off with a custom solution for one company, then generalize it to other companies in the same sector, and then to other sectors.

I've worked at companies that have started both ways. The techie way tends to be more spectacular both in successes and failures.

Re:Get a sales force and some customers

[Kohath]

If he were going to start the next Google, he would be talking to his venture capital friends and his other advisors, not to AskSlashdot.

Re:Get a sales force and some customers

[turbidostato]

"Business is about sales and customers. Everything else you do is completely irrelevant if you don't have sales and customers."

Tell that to Google, Facebook, Twitter, Whatsapp, Pinterest, Skype...

Re:Get a sales force and some customers

[Kohath]

Which one of those is "a software shop"? None of them.

Re:Get a sales force and some customers

[Noah Haders]

for a startup, "sales" is getting funidng and then getting aquired. "customers" is VCs and larger slower companies in the same space. nobody gives a fig about any users.

Re:Get a sales force and some customers

[wvmarle]

That for six out of at least six million businesses the amount of sales and customers doesn't matter too much, doesn't make it the new rule.

Yes, they're big. But no, you won't be one of them. Unless you somehow win the lottery when it comes to having the right idea at just the right time.

Re:Get a sales force and some customers

[turbidostato]

"Business is about sales and customers"

Where does it says it's talking about just "software shops"?

Re:Get a sales force and some customers

[turbidostato]

"Yes, they're big. But no, you won't be one of them"

No, I won't. My point is that these companies have forced us to "think out of the box": they show that the old "business is about sales and customers" is the absolute truth no more.

Re:Get a sales force and some customers

[muridae]

Bull, all of those businesses listed have "sales" and "customers". They survived the period where they did not have enough sales on VC and angel funding, loans, and lots of debt where needed. But once they grew past that, once they shifted from "projects" into "businesses", they had customers. We, the average users, are not their customers. We don't pay them anything. Ad agencies pay them, big companies pay them, or buy them out-right. Those are their customers; they are the ones who keep the lights on in the buildings. So in the end, once they became profitable, they've fallen back into that truth about business.

Want to know who their customers are? Go through their stock filings and look at who is paying them. Few of the ones listed are still running on VC and debt.

Opening a software shop is not how to go about it

[TropicalCoder]

Especially when you lack experience, that is a setup for disaster. Instead, just start developing a marketable product out of your home. If you need help, contract someone over the internet. Grow organically from there, one step at a time. When you finally have a marketable product, then maybe you need to start worrying about sales and lawyers and all the overhead that goes with a business. By that time, your thinking will have matured.

Mod parent up.

[khasim]

Isn't the most common scenario for these enterprises where the programmer's customers grow beyond his ability to support just by himself?

So he starts adding people to handle the portions that he cannot, efficiently, handle himself.

If you're going into this wondering what the "ratio of senior programmers to intermediate and junior programmers" should be then I think you've skipped too many steps.

The same with "different tools and/or languages". The 2nd programmer uses exactly what the 1st programmer uses. The idea is to provide support for the founder so he can focus on what he is good at.

Re:Mod parent up.

[rasmusbr]

It's actually pretty common for the founder to be someone who doesn't have any technical knowledge or any knowledge of managing the finances of a business. The founder could be a person who brings money and ambition to the table. (I'm not sure if this applies in this particular case, but it would not be unusual).

The most important decisions then are usually the first 2-5 employees that they hire. The first person must be an experienced, ambitious, loyal and tireless person with the right technical knowledge who for some reason prefers to work for a tiny startup instead of a larger, more established company.

Best of luck!

Re: Mod parent up.

[umdesch4]

Well, there are reasons beyond that to be fair. Thinking of the reasons why some of my previous jobs were in large corporations:

- More likely to get training when you're starting out and wet behind the ears, be surrounded by people with more experience you can learn from, and not have to be the guy with all the answers when you're so junior.
- A certain level of job stability and good benefits when you have bills to pay, and people you're supporting.
- Something recognizable to other employers for your future job hunting.

Having said all that, you're right about one thing. If you stay in IT long enough, and you're good at what you do, there does come a point where, if you've worked for large companies for a while, you realize how crap it is, and that you deserve better and can get it in a smaller shop, or startup.

Re:Mod parent up.

[w_dragon]

The founder should be a subject matter expert. They should be the one guiding the product to the first release. Unless the product is a compiler it doesn't matter much if they can code. They need to have a vision of what the product will be, not what widgets are required for every function.

Re:Mod parent up.

[ILongForDarkness]

I agree. You have a good idea and domain knowledge. Next up is finding the passionate hacker that can say "yeah but" and get all the crap out of the idea, figure out how your idea for an internal document management system could be GoogleDocs instead etc. Sometimes it is the business person that finds the market and sometimes it is the technical person that finds the problem that the idea solves.

Re: Mod parent up.

[Bengie]

Job security has its own value, along with enjoyment. You can't base everything off of the pay.

Re:Mod parent up.

[Hognoxious]

It's actually pretty common for the founder to be someone who doesn't have any technical knowledge or any knowledge of managing the finances of a business.

Are we talking founders in general, or founders of companies that survive long enough that we've actually heard of them?

Re: Mod parent up.

[unrtst]

Job security has its own value, along with enjoyment. You can't base everything off of the pay.

Job security is a myth.
You're only chance at job security in a large company is to do what the GP stated, "so they can hide in a corner doing minimal work while collecting a mediocre salary".

Those tireless technical people will actually have better job security at a start up or small shop. They often need a lot of things that large companies frown upon, like flexible hours (to support binge sessions of 18hr days busting out some new thing), some level of control/authority over design and business decisions that would otherwise get delayed with red tape (ex. purchasing several additional servers to support some new thing/design/etc; if it's delayed, it'll ruin their momentum), lower overhead of stupid rules and meetings and such allowing them to focus, etc. These *can* be had at a larger company, but its rare, and it's not often tolerated.

I can't speak for the GP, but I doubt he was basing everything off of pay. That sounds like one of the least important factors, but it doesn't hurt the decision.

Re: Mod parent up.

[g4sy]

tireless people at bigcorp have no job security because they are a threat to be fired asap

Re: Mod parent up.

[g4sy]

i forgot a significant comma there. sorry

Marketing

[houghi]

Looking at the successfull software companies, I would say that marketing is the most important part. No matter how good or shitty your product is, if your marketing is good, it will sell.

Instill confidence through source escrow

[SethJohnson]

If you are planning to sell software to the government or business as a startup, consider source code escrow. Your customers will tend to stick with established vendors for fear of you going out of businesses and leaving them with an unsupported implementation. The source code escrow is insurance against that being more of a catastrophe for your customers than you.

Invest in dedicated technical support. It plays up as great comedy in the movie, Office Space, when the character says you don't want the customers talking directly to the engineers. You actually don't want that. Establishing a quality support team keeps the engineers productive on developing while the support group ensures the customers are getting help with their issues. Oh, and don't outsource this responsibility to a foreign country. If you think you can't afford quality support, at least staff it with a recent college grad and split that person's time between support and bug fixing.

As far as building a team goes...

[u38cg]

...I would strongly recommend just getting the best people you can. In my experience good, experienced people in a small team do not mind picking up the grunt work if the team is pulling together and being productive.

Re:As far as building a team goes...

[BarbaraHudson]

t plays up as great comedy in the movie, Office Space, when the character says you don't want the customers talking directly to the engineers. You actually don't want that.

Sure you do. The person who wrote the bug or badly implemented feature gets first-hand knowledge of how it impacts the customer, rather than filtered through someone who is just playing "broken telephone" and doesn't have a working knowledge of how the thing actually works.

They also get to find out that 3/4 of the "must-have" features that "the customer requested" were not customer requests.

Besides, many support contracts provide for direct access to an engineer in those cases that require / pay for it. And as you lack the necessary experience, you don't know what to ask.

The customer doesn't expect programmers t be wearing suits and ties, so don't worry about the impression they make, as long as they don't have Tourettes. "Ah, but this one isn't a people person!" Then you should have hired someone else - you don't have the luxury, as a start-up, to hire people who can't serve multiple roles.

Manage the Culture

[heretic108]

Above and beyond any specific policy areas such as coding standards, seniority mixes and son on, the biggest and most important thing to manage is the overall software development culture. If you can energise the culture, and inspire people to believe in the mission, to fight for it like their own flesh and blood, as well as to honour each other's diversity of perspectives, you will achieve far more than by drawing policy lines in the sand. Keep it fun. Make the crew feel special. Give them a feeling that their futures are within their control.

This said, I would also recommend frequent peer code reviews - this will inspire better work, knowing that people are accountable to their peers. Also, be on the lookout for single-sourcing, and fight it off like the plague, even if it has a productivity cost. Yes, Natalie is brilliant with the middleware. But what if she gets hit by a bus, or leaves to have a kid? Defend in advance by ensuring there are others who can instantly step in and take over from her.

Again - an energised culture with a strong team spirit - a deep and powerful soul - will optimise the workplace far better than any arbitrary standards.

Keep the money close

[petes_PoV]

I'd like to start my own software product line and I'd like to avoid outsourcing as much as I can. I'm seeking advice on what you think are the best practices

The two "best practice" points that I know of are linked.

The first is to have a great deal of money - far more than you could possibly think is necessary.

The second is to be very careful, to the point of stinginess, on what you spend it for,
I would work on the assumption that it will be a year before you see any invoices getting paid and during that time you will have to pay out for both the startup costs and the people you employ. Since people will be the single biggest cost item, employ as few as is possible to get away with and work them as hard as possible - but only on things that will contribute directly on creating income. And then, only on short-term income.

Once you do that all the high-level questions will either answer themselves (and usually the answer will be "no") or they will turn out to be irrelevant to the immediate survival of the enterprise.

Re:Keep the money close

[BarbaraHudson]

The first is to have a great deal of money - far more than you could possibly think is necessary.

1. How much will it take.
2. Quadruple it.
3. Add a zero.

Youre going to get a lot of stupid advice.

[Zurk]

Heres the deal :
Youre going to get the following advice :
1. Hire a professional to run/manage/accountant/payroll etc and you can never do anything properly.
2. Youre an idiot - stop dreaming!
Both pieces of advice are flat out wrong.
To start an actual business you dont need professionals, funding or being extra smart. What you do need to do is not listen to idiots and learn. thats it.

Heres what you do :
1. Start your business. That is - go out into the world and find someone willing to pay you CASH MONEY in large chunks for doing something. Thats at least $2000 cash on delivery of x product.
2. Put that $2000 towards your business expenses. Now go find a lawyer who incorporates businesses federally with $2000 AND make sure you have enough of it left over for a mailboxes etc address, domain name, google apps subscription for mail, web address, business cellphone and rental meeting room in a office rental place. This is your "Start up capital" or "Seed round".
3. Now go develop that product yourself. Send it to your client. be prepared to gain $0 from this transaction since your client will likely dump you after seeing that first product.
4. Develop the product some more while looking for other clients.
5. If you find any, congratulations ! You have a business!

This is how I started several years ago. Bottom line is in 2 weeks you must be break even and in the first month you must have enough to meet payroll. If you do youre fine.

Know what you're going to do

[wvmarle]

The summary is a bit short on detail, but one thing is lacking: a business plan. I've never run a software business, but am running my own business now so have a bit of experience in setting it up. What do you want to program? Who are your customers? Where's the demand?

You're already talking about hiring multiple people - this means you must have a decent outline of a piece of software to develop, and it's going to be a quite big project. Do you have customers for that already? Without customers, you're going to run dry very very soon, and you won't be able to get any funding. No customers, no future for whatever you want to do. Just saying "let's set up a software shop" is a one-way street to bankruptcy. You need to have potential customers before you start producing anything, really. You need to know the demand is there. You need to have your income sources. You'll have to find customers who need a product, and who believe you can deliver what they need at good price and quality.

Hiring people is very expensive for a shop without income. I've always started up on my own, do everything in house until you have too much to do that you have to start getting other people involved. In the meantime this also means that revenue is there.

Getting started is hard: no-one knows you, and hiring you (the new kid on the block) for some big, expensive software project (the kind a single person can't handle) won't happen. They'll go to the ones they know that can handle it. You'll have to start small, slowly get your way into the market, get your name out, get your product out, let the people know you're there and you're good. Then you may get bigger projects, then you may start hiring people and setting up an office that's not part of your living room.

Good luck with it all!

Re:Know what you're going to do

[BarbaraHudson]

Maybe he's in India and wants to be the next Tata or InfoSys? There's obviously a market, cheap local labor, etc., and the quality doesn't have to be high.

Re:Know what you're going to do

[muridae]

You can start a software shop on a $0 budget, but you will only get volunteers.

Well, let's revise that, you need your domain name, website, incorporation papers, and contracts with your volunteers. It's not $0, but it's not several thousand either. I've offered some of my free time to a group doing this; though it took some convincing from me that getting a proper contract written up was infinitely safer for them. Everyone just offers their free time, and the project gets built; end result is getting everyone involved to have some share in learning the ropes of the industry without the gigantic risks and investment of starting a development house with no product in sight.

Chances are, if I can get my video game design to the point where I feel it would make a viable demo, I'll probably use the same model and offer future profit percentages for folks to handle the stuff that I don't do well (HCI, pretty models and textures, story, etc). Who knows if it will work, but incorporation is only about $100 here, and a visit with a lawyer to draw up a boilerplate contract is about the same.

The difference is, the group I'm working with, and my future project, both have a target audience and a goal in mind (i think, anyways). The OP doesn't elaborate on points like that enough for me to feel confident that they know what they want to develop or who it's for; questions like "should I allow multiple languages" would be dictated by what product you make. OS driver software: write in C. User interface for someone else's code: write in any language that the devs like that will link to the other code. Video game? Write your engine in your choice language (or your engine's languages of choice), and if you need some script-able stuff for your world developers then throw in a link for Lua or Boo or something high level. Statistical stuff? R and SQL. The target audience sometimes defines the answers to the OPs questions.

Re:Know what you're going to do

[wvmarle]

What do you need these volunteers for? If you can't do something yourself, you have to hire someone to do it for you, however most businesses start off as a one-man shop. Many of those never grow beyond that, they provide the owner a good income and that's it. Many owners may not even have the ambition to grow further, to start having to manage people instead of doing the real work (which they enjoy doing). That accounts for all businesses, including software businesses, this are just businesses where a person is self employed, selling his services directly to the people that need exactly that.

OP doesn't even mention what kind of software he wants to do (other than that he can't write software himself). There's web design, there's database development, there's custom application development. All these things can be done by a single person. I've done just that for my own business: I'm a tour operator and I happen to be pretty computer savvy, so for that my business set up a web site (to promote my tours), an online booking system (accepts credit cards - using PayPal as payment processor), a MySQL database to store all the tours and bookings, a front-end for me to manage tours and bookings. I've designed promotional leaflets and a presentation for use during the tours, explaining geological processes that took place. Besides all that, I'm operating the actual tours, and no way I'd hire someone to do that for me as that's the fun part of the business.

Yet still I'm a one man shop. I haven't hired anyone to do this for me. I haven't even set up a company for that (not legally required as long as I operate using my own name). The only thing that I outsource is stuff that I don't have the equipment for such as the printing of leaflets, and I'm renting a cloud server to run my website on.

What you're thinking of, is far more difficult to make money with. You have to have a unique idea, have to be the first, have to implement it well, have to get the idea out to the people.

On the other hand, there are lots of huge, established markets (such as tourism - what I'm currently involved in) with many businesses providing income for many people. The trick is to get into such a market, and make some of that money flow your way. It usually won't make you super rich, it won't make you a second Google or Facebook, but the chances that you can make some good money in such a market are good, while the chances of making it super rich are very, very, very small. Buying a lot in the lottery gives you a better chance to strike it rich than hoping for a unique product that takes off massively.

Re:Know what you're going to do

[muridae]

By volunteer, I mean someone offering skills in exchange for share of future profit (which isn't always monetary). For the project I'm "donating" free time to, there is no expected future profit; I'm doing it because the project seems fun, others want their name in the industry, a mark on a resume, each is getting paid in some way that isn't monetary. Similar to coding for FOSS projects. For my game project, should I ever decide it's worth doing, the payment would be share of the company which requires the promise of future profit and requires an incorporation. Note that I'm donating my free time to this project, I'm not employed by them; but a contract/license is still helpful because it dictates what they can use my code for and what I can expect if they somehow got bought out for billions of dollars.

What I was offering insight into is the way garage developers worked in the 80s, or the way small college groups sometimes work. Since the OP wasn't specific, I wanted to offer some ways that one can work that don't use the normal "save money from day job, quit, invest in own company" method that can and does work. It isn't a model that works in many other industries, and it often requires that your work force still has a day job or other source of income. Most of those garage developers go no-where, a few get bought out or hired by the big boys (Skype), others displace the big boys of their time (Google). If the OP was truly passionate about whatever type of shop they want to set up, I thought some insight on how some FOSS projects operate might be usable. I mean, Mozilla, Ubuntu, WordPress, MySQL, and a bunch of others show that the initial model can work as a stepping stone.

Spotify engineering culture

[Anonymous Coward]

There's an interesting video about software shop culture from Spotify: https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/

Misery

[DudeFromMars]

You are volunteering for a lot of misery. If you must persist, read Steve McConnel's "Rapid Development" - He lists all the normal pathologies of software development. Also read Steven Blank's "4 Steps to the Epiphany" - about the normal pathologies of the software business. The problem with reading about the mistakes everybody makes - you won't believe you will make the same mistakes. You will of course painfully repeat each mistake, guaranteed.

So yu want to be a software shop...

[FlyingGuy]

The best replies I have seen are from Zurk,& Kohath so let me add to that.

Either develop a market or a product that will fill some segment of a market, first before you do anything.

Now let me suggest that you target a market where the predominant players have become lazy and charge a LOT for their software.

This company Zemax started off when optical design software had a few big players. Their software, on average was selling for $30.000 US per seat. The company founder got a PhD in optical design and while he was still at school started writing his software. What he did was build a PC based optical design system that did 98% of what the big players did. But in that 98% he included what a lot of people term is that last 2% which is the really hard work. He left a lot of the simpler things for later. When he released version 1.0 he sold it for $2500.00 per seat ( with the hardest dongle he could buy at the time ) and after the first month he was moving ~ 10 units a month. In 20 years his price for the basic software has only gone up to $3600.00 a seat.

Make no mistake he worked his ass off to do it, he did it by himself for a long time before he hired his first employe. The company is still privately held and the man stopped having to work for a living many years ago, but he still does it because he loves what he does.

Re:So yu want to be a software shop...

[Krishnoid]

but he still does it because he loves what he does.

A very, very relevant piece of wisdom contained in your advice.

Standardized and simplify as much as possible

[sleepypsycho]

I strongly recommend keeping the same set of tools, language and build. Each different element adds overhead. With a small group you can't afford additional overhead.

It is likely that everyone will have to handle multiple aspects of the project. You will want multiple people who can wrangle the build and the tools the better.If everyone is sharing the process then it is easier for the team to be flexible and make the best use of the individual. It also means a relatively experience set of developers. Look for people who have shown flexible and wide variety of interest.

A clear process is also critical. Whatever system you use make it clear how decisions are made. Code review or pair program is required. You don't want to rely on one person to develop a critical system and then find out it is a mess or that no one else is clear on the mechanism.

Re:Standardized and simplify as much as possible

[Euler]

Really good advise about adding overhead. Trying to choose the perfect coding standard, tools, language, etc. should not be the thing to spend time on at this point. If that is the thing that interests you most, then just keep this as a hobby/self-guided project experience for future job interviews.

But for a commercial product - just choose tools/languages that you already know that are reasonably applicable to the task at hand. However it should be something mainstream that will be supportable: new hires will need to adapt to it, and you want to make sure it will be maintained in the future. You have to put your time into developing and selling the core product.

For choosing a coding standard, that will be a headache as you hire more people. It can be a potential ideological battle among your employees, and you have to really evaluate how much a particular standard will specifically improve productivity or quality in the long run vs. hinder or irritate your developers. Some industries already mandate specific coding standards such as MISRA or DoD specs, but for most companies that isn't a factor. My personal feeling is that if you are going to enforce coding standards, you could better spend that time and political capital with your employees by instead reviewing code for mistakes in general perhaps? When you find a particular bug, make sure you have drilled down and found similar cases, etc. Document so that you remember to look for this in the next code review. You will end up with a more robust process rather than imagined cases where code style is an issue.

don't let customers walk all over you

[bzipitidoo]

Especially in software engineering, which is notorious for being difficult to estimate, customers are always paranoid that they are getting a bad deal, and often compensate by making excessive demands. They will try to put the screws to you, threatening to take their business elsewhere if you resist their extreme demands. You have to finesse that kind of pressure. Not an outright, flat no, but counterproposals that won't break your company. I've seen more than one business fail because they didn't push back hard enough. Sometimes the customer got what they wanted, at far too low a price and then the vendor folds, and sometimes they didn't because the vendor folded before delivery.

This problem is harder to avoid than it might appear. in one case, the company was screwed by their own employees, that, to be fair, they had put in a bad position. The employees were told that if the company didn't win the contract, they would all be laid off. So what happened? The employees did anything they had to, to win the contract. They lowballed their own company. They severely underestimated the effort and work required, coming up with a plan that called for the job to be finished in just 6 weeks, with another 6 weeks margin of error. Even the customer was doubtful that the work could be done that fast, but the deal was so good, from their point of view, that they accepted. Why management approved it, I'm not sure. Desperation maybe? They blew right past the 3 month mark of course. A deathmarch was nowhere near enough to compensate. After 8 months, they managed to deliver one working part, just enough so that the customer grudgingly decided not to sue them. The customer had little appreciation or sympathy for the vendor's plight. The rest of the work was abandoned. The company lost a lot of money on the deal. One bad deal wasn't fatal, but they made several other bad deals, and those were enough to kill them.

It is a BUSINESS

[LynnwoodRooster]

Books, sales, marketing, employee handbooks, Government required postings, vacation policies... Get that stuff in place before you start hiring. Then treat it as a business - regardless of what your product is.

Re:Basic advice I have been giving for a few decad

[BarbaraHudson]

Contradictions here:

Pay them as sub-contractors

... and ...

Have a senior programmer mentor a low-level programmer that would include code reviews and/or doing some lower level support for the senior programmer.

Even if they normally telecommute, that doesn't make them a sub-contractor. What makes them an employee are things like being mentored, being given detailed instructions on how to complete the task, etc.

Here's what the IRS says:

How do instructions and training affect the employment status of a worker?

Instructions and training provided to a worker are important factors to be considered. If you give the worker detailed instructions on how work is to be done or train the worker to perform tasks in a certain way, the worker may be an employee. A subcontractor does not need or receive detailed instructions or training on how the work should be done.

Re:Opening a software shop is not how to go about

[vanye]

I would agree with that - but I probably wouldn't skip the lawyer part.

You'll want to ensure that you own any product that is written.

Two cents...

[bayankaran]

The most important part of any business is "cash-flow". You get that right and your business will be a success in conventional terms.

Your questions on different tools/languages do not really make sense unless you are clear about the product you are pursuing. The same about senior/junior programmers.

Though you don't want a take on Agile/Waterfall, from my experience any project which involves serious "design" works better in a waterfall approach because most of the phases of "design" may not be flexible to be accommodated in a two week sprint cycle.

Hiring people with a clue is harder than it looks

[Kjella]

At a consulting company I used to work at we defined our "core processes" and in a bizarre act of simple self insight - probably because it wasn't billable - they found we had two:

1. Sell
2. Deliver

You're the system architect, are you the one doing the selling? Because I can't stress this enough, if you're not making sales you're going out of business fast. Even if you don't need a traditional salesman somebody has to promote the product in all sorts of media and get the word out to all your potential customers. The other part is having at least one guy who really groks code, since you're not it. You're going to produce a version 1.0 and it's going to have rough edges and it's going to have bugs. You won't have the to do all the things you'd like to do because you need to ship and make money, so stay on top of your early clients and make sure what bothers them is a top priority.

Is it a database-driven UI application? If so make sure you got database design experience as horrible table design and data inconsistencies will come back to haunt you, user interface designer who can also double as technical writer so your users actually understand to use it - this is also far harder than you think - in addition to the generic data processing skills. And really if that's three people, one salesman and if you haven't even started yet I wouldn't plan past that at the moment. If you're still alive and making money and looking to expand then you can start considering the rest. You'll quickly enough see where you need more people because you're out of resources, don't forget that the primary concern is running a business and secondary keeping your employees happy, if you fail at the first you fail.

What is a "software shop" ?

[vanye]

Sounds like thats a consultancy company.

I've only ever founded product companies.

Here's how we did it.

1. Socialize, find other people around you that have complementary skills and who also are interested in doing their own company (our first company had an general business person, a PhD and an engineer)
2. brainstorm, find gap in the market, find new product idea.
3. make big decision to quit current job
4. form company to hold IP and who owns what - this requires an initial set of capital - $20k. No IP - then what is your value ?
5. Develop prototype. I (engineer) started working on prototype full time (using my savings to pay expenses), business person started building product contacts/approaching customers...
6. As prototype develops consider external funding (VC) (until now we were self funded, CEO funded lawyers, I funded my own time - compensated in additional stock). Additional part-time developers were brought for stock. There should be people you know (and trust) - they will be the seed of the engineering organization. We had 2-3 - more and I would spend too much time managing.
7. Once we had funding, bring on existing developers full time, start looking for additional engineers.
8. Release initial product (4months after funding - 15 months after initial line of code written)

Key take away - a start-up is hard, you need to work with people you trust. If you're an engineer by inclination, stay in engineering, your start-up is not the time to be experimenting with new roles, you'll have enough to do just making sure your piece works since you're in charge... Remember that you're responsible for others giving up their secure jobs and committing to work for your idea, treat them with respect and share the wealth unequally but fairly (yes, unequally you've taken additional risk, they haven't).

Second followed a similar route

The actual tools are just details, you should be spending all your time working out how do we make this successful - not should we force highly motivated developers to use EMACS...or vi or

Its not important unless your product is EMACS....

Some easy and obvious advice.

[smartin]

- Make sure the everyone understands and agrees with the big picture.
- Make sure the people are invested in the end result. (this with the point above says that outsourcing is not the best solution)
- Be consistent, thorough and write high quality software. Coding guidelines and a clear process that everyone understands and follows will help with this.
- Understand that the idea is more important than the implementation, but a poor implementation can ruin a great idea.

Getting Real

[Art3x]

Just read Getting Real . I was thinking of recommending their second book, ReWork, but it's mostly a rework of the first. You either get Getting Real or you don't, and if you don't get it, you have problem about getting real.

Re:Use standards now

[turbidostato]

"I work at a company where there haven't been coding standard until recently, so there were many years where a few programmers just made stuff work. Well now you come up behind them and it may take you hours to understand code that you could have understood in 30 minutes or less if it was readable and maintainable code."

Yeah, well, you know, owning a business is about trade-offs. Maybe if they were focused on processes and standards they wouldn't have been able to focus on producing stuff that just worked and then they wouldn't have employees by now to sigh about how hard their work is because of the accrued technical debt.

It depends

[putaro]

Most of the answers to your questions are "it depends" I don't understand what you mean by a "software shop" - is this a consulting company, a company that produces a large scale product, a company that produces a small product, an online service or what?

Your ratio of junior to senior developers depends on the kind of product you're producing. If you have an application that has a big, overarching architecture and then lots of relatively simple modules for specific cases, you want many junior developers to pound out those simple modules (e.g. different types of data entry screens).

Coding standards and standardization are always good. For a small shop you're best off looking around for one that you like and adopting it rather than trying to make your own from scratch because it is not a revenue producer and you can burn endless hours in meetings arguing about spacing, comment style, etc. Make an executive decision and move forward.

Tools and languages, again, it depends. Use the right tool for the job.

Since you don't know any of these things or how to make the tradeoffs, what you need is to hire a director of engineering who does because if you try to hire some developers and apply the vast depth of wisdom that you've acquired from this thread on Slashdot you're probably going to fail miserably.

Buzzword bingo, but with sincerity

[WinstonWolfIT]

Retain a consultant with a proven track record to implement your processes.
Hire only senior level devs who can do solo heavy lifting across your technology stack.
Deliver small increments of potentially shippable product.
Insist on emergent architecture.
Empirically adapt into better processes.

Did that, a couple times. Jump 1 employee to four

[raymorris]

That's what I've always done, grown each business slowly, organically. I've since learned that there are two types of companies that work well - tiny ones that basically provide the owner with a job, and larger ones run by a management team.

    What I did for far too long was deal with payroll, unemployment taxes, health insurance, sick leave, etc for two employees. That was a mistake. I should have chosen to either stick with just me and a part time helper, or make the jump to six or eight employees. That jump requires a leap of faith, some investment and a marketing campaign. Not making that leap meant that the business was dependent on one or two long -term employees who occasionally get sick, leave the company, etc.

Be tiny for a while until you figure out what you're doing. That may mean doing your business and a day job for a little while until the business provides you with a full-time income. Once it pays you $60,000 / year, then decide to either stay at that level or increase revenue by 500% quickly. Especially after the changes in the last six years, being an employer takes a lot of time and effort. Make it worthwhile. Do a POC by working it by yourself first, though.

Small? Specialize and get billing, taxes, ...

[Qbertino]

Small? Specialize and get billing, taxes, legal and ERP covered. Legal and taxes are other people, billing an ERP can be done with online tools like FreshBooks or small to midsized softwarepackages like Lexware.

What practices you need is up to you - especially if you code alone.
It also depends on the code you write. If it's just custom ABAP scripting for a handful of clients at a time, point and click testing and a few manually checked testpositions ought to be enough.
If you want to deliver software to a wide range of customers, perhaps even online, with demo-versions and stuff you *have* to have your pipeline standing, even and especially if you are alone. You want to be able to compile and deploy a hotfix wih a mouseclick.

Ask yourself: if the worst possible szenario happens with my software, will I be able to fix it inmediatel? If the answer is yes, with a few night-shifts and my leet Google searching skill I ought to manage somehow - that's OK. If the answer is no, compiling for XYZ takes days of time each time around - then you're doing it wrong and need to automate your process (more).

As for the business itself: Specialize in a field and a subset of that. There is no other way you can keep up with the big boys as a small shop. ERP, Web, Embedded, DB, etc. They all have their ups and downs and each have countless subcategories you can specialize in. Do it! Do not look left or right, unless you don't have any customers in the current field.

Good luck!

Ask these questions first

[dskoll]

Before you think about how to run your shop, ask these questions:

Do you have a product?

Is there a market for that product? How do you know?

Do you have a business plan including a marketing plan?

Once you get past those questions, the rest is easy. Outsource anything that doesn't make sense (HR, accounting, payroll) and keep your core expertise in-house. Don't obsess about coding standards, etc. until you have cash flow. It's far more important to do your utmost to get the business making money thatn to worry about programming minutiae.

I did start a software product business back in 2000 and it's going strong. The very first person I hired was our VP of Sales and Marketing. I didn't hire another technical person until employee #5, so didn't have to worry about imposing coding standards on others. :)

My worry is not your domain experience

[msobkow]

My concern is not your domain experience, but your business experience. It sounds like you're approaching things from a largely technical viewpoint, and that's going to get you in trouble with running a business. Your focus, first and foremost, should be on revenue, a product portfolio, and a plan for growing the customer base.

Sure you'll need an accountant and should outsource your payroll and get a corporate lawyer on board and all the other things people have advised you to do, but first and foremost, you need to get your head around the idea that you're no longer going to be an engineer and will have to focus on business needs and decisions that would apply to any industry.

Make it require outdated browsers and Oses

[Billly Gates]

Then turn around and offer it fix it for a very inflated price once websites wont render anymore after you force them to use your product. Make sure it ties into as many business processes unrelated to your product selling points as possible so your customers can fire people who do the things your software does. Therefore can't leave you when done.

You will go well in the medical industry especially.

An answer

[corporate zombie]

First, don't go it alone. If you can't find a few friends that you can convince that you are on to something with whatever product ideas you have then you aren't on to something.

Software development is a team sport. Even if the other players are you in 6 months. Have coding standards. Have have your IDE or some program enforce them. Write documentation. Use version control. Use a bug tracking system. (Yeah, all that stuff you've read is best-practice... it got published as best-practice for a reason.) As a startup select a "major" language but for scripting just accept that any of perl, python, ruby, bash are fine. Train, mentor, and grow your people. You want really good generalists at this stage and not experts that can't also do ops, admin, front-line, etc. Using open-source software is a force multiplier. If you are going to extend OSS just make sure that your product value is in the data you are generating and not the code (since you'll be giving the code away for free).

You'll want to find people at least as good as you are for raising money, marketing, sales, product development, and IT (assuming you'll be CTO/VP Eng and leading development; if not find a CTO [tech strategist to put in front of investors and give you something coherent as far as technology goes], and/or a VP Eng [developer+manager who can wrangle the cats and makes sure product gets delivered when product is supposed to be delivered]. Coming from the tech side of things do NOT undervalue marketing, sales, and your CEO. The better mousetrap will not sell itself. At the same time while a great sales guy can sell snow to Eskimos they won't pay a lot for it. Find/build a team that covers each others weaknesses.

Gonna stop here. Could go on like this for a while since this is what I've been living the past 4 years.

Blogs in no particular order: Joel on Software, Paul Graham, any other 2-3 of the top tech incubators in the country (Google em).

Finally, ignore anything above that doesn't make sense for the business you are running.

Advice from a software entrepreneur

[st0nerhat]

I started a business right out of school with just a vision and my CS degree. We are still in business today, 10 years later. The secret to success for me was twofold: * I went into business with two equal partners. They compensated for my weaknesses and were able to provide initial sweat equity for the business. There are also some do or die trials early in a startup and its easy to give up if it's just yourself but harder when you would also be letting your partners down. * We had a strong network of mentors who connected us with potential customers. I read a number of the comments in this thread and I have some thoughts: * You don't need a full business plan. You can pay someone to write that to get VC if you need it down the road (worked for me). However you do need a plan. How will you finance initial development? Can you name your first customer? How large is the potential market? What is the minimum viable product? * You absolutely can run a software business without having ever been employed in a software company. I figured it out. It's not an easy road though. * You must be an excellent salesman. If you are not, pick a partner that is or you are going to be handicapped. I've seen so much crapware sold for big bucks because the salesperson was talented. I also believe salesmen are born, not raised.

Re: Advice from a software entrepreneur

[st0nerhat]

I hate replying to my own posts. Just wanted to apologize for the horrible formatting.

Re: Advice from a software entrepreneur

[MooseMiester]

Hello St0nerhat, very good advice from one software company owner to another, just gave similar advice...

Re: Use standards now

[st0nerhat]

Exactly. If a company is in business, then it means they made mostly correct decisions up to now.

Have standards and force them

[roman_mir]

I started this way as well, here is an advice: have strict standards and do not let anybody violate them. You will have plenty of work to do, do not make mistakes of allowing standards to slip from the start.

Get fresh out of school people, maybe even people without full degree, pay as little as possible, you have no money to throw around, but make sure there is always coffee and food in the house, besg way to keep morale up is to have people who are not feeling hungry.

Get cheap or free stuff from craigs list, you will need computers, monitors, switches, cables, test servers, desks, chairs, some plates, forks, spoons, cups, a microwave, a kettle, a coffee maker, fridge, paper towels, bathroom tissue, buy in bulk from costco.

You need to be proficient enough to write/read code, who else is going to do it at first if not you? You do need standards, would be nice to pick a technology and stick to it, so make your picks. Some code generators would be nice too.

  Prepare some document templates for proposals, design docs, business docs, release docs. It is very useful to have an accountant that knows you and can deal with the payroll,source deductions, etc.

Find clients outside of your country, but if you are an American you will have tough time opening an offshore bank account, which you need...

Good luck, you will need plenty.

PS. May want to consider a couch in the office.
PPS. May want to consider renting a house instead of an office, you can live there and have enough space for work.

Standards and methodologies

[codeButcher]

Many others have already mentioned that for a 1-(+-)4 person "company" admin, payrol, HR, legal etc. can take up a lot of those resources' time (or money, if you get in an employee to do those), which could rather be spent on doing your core (technical) work. I have seen it time and again.

I want to chip in about the general topic of standards and methodologies. Please remember that one isn't (necessarily) better than the other - they are all simply tools working towards a goal and you use whatever tool works best in your circumstances. Now, your GOAL is the important thing: communicating between different members of the company (communication over space) and remembering (communication over time) - which sometimes is important even if you are one person. Using a formal standard to do this should accomplish several things:

• All members speaking the same "language" or format (know what to expect);
• Things should be stored in a physical or electronic medium (well-indexed), not in brains, so that interrogating that source takes only one person out of his task and not two (or more);
• Should enable the organisation to function as an organism distinct from the people that make it up - so that people joining, leaving, or just turnover influences as little as possible;
• Should be adaptable, because the organisation (from the previous point) should be a learning and developing organism.

IT vs software development

[ILongForDarkness]

I'm not sure this thread is giving the poster enough credit it depends how hierarchical his last job was but in my experience IT/systems admins can have WAY more business experience than software developers. Often they handle purchasing of IT equipment meaning interviewing users and determining needs, specing out the boxes, finding a vendor etc. Since the users cross the corporate spectrum you get exposed to the business practices and relative skills of different departments which can help greatly when you realize that for example a good records clerk might be a wizard with Excel but otherwise be an idiot with how to use a computer, but that is okay they can still do their job.

Often they have to handle reporting in order to allocate the expense back to departments, have to write or help explain the corporate IT use policy in such a way that it conforms to regulations etc.. Managing a much more complicated budget (service contracts, internal and external employees, equipment purchasing and refresh cycle etc: it can be much closer to running a smaller business within the bigger business. In software development it is much easier to just become the guy that makes the widgets and doesn't have to worry his pretty little head about how it is used. At best, again in my experience, dev managers can manage people hiring and allocating to projects to try to keep the projects going. They have little experience managing other types of resources.

I agree just having a masters degree doesn't mean you are ready to run everything. Corporate culture vs university culture is completely different. Spending grant money you've convinced someone to give you for the next 3 years is much different than spending money you are borrowing from an investor/bank/your personal retirement savings in hopes of making a business that will be profitable. In university it is often okay to say: we experimented and proved it wasn't a good idea, in business it is waste and needs to be managed or you'll quickly be out of business.

Not looking good

[gatkinso]

You haven't even started and you are already bogged down on "coding standards" and "best practices."

In The Beginning only one thing matters: robust code that does what you want it to very well. Maintainability? Pah - you need a future for that to matter. Best practices don't matter if you are bankrupt, or have a product nobody will touch.

Personal experience as an employee

[Required Snark]

I will tell you how it works from the other side of the fence.

First, find some area with a high cool factor. Cool can be substituted for almost anything else, like management.

Find potential employees who are obsessed with your cool idea/company. There are two equally important characteristics that these people must have: they must be really smart, and they must be ready to do anything to make the cool happen.

Promise them two things: they will help change the world, and any sacrifice they make now will pay off in big bucks when you succeed. Pay them a moderately OK salary, but not anywhere near the high end. If pay ever comes up talk about cool, loyalty and payoffs in the indefinite future.

Work them until blood comes of their ears. If possible cater their meals, so they spend all their time either at work or with their co-workers. This keeps them from realizing that you are stealing their life. It helps if you can find single people, or couples where you hire both people. Social ties to non-employees just cause trouble.

Raise money, get customers, and go into panic mode. Take the people you have hired with no management experience and make them manage stuff. Don't hire professional managers because it is a waste of money and time. Also, if they know that you are making mistakes, they might challenge you and make the staff start wondering if you know what you are doing.

Pay yourself very well, but act humble. If the place is small, take people out to lunch or dinner a lot. It's tax deductible, and it makes them think you give a rat's ass about them.

Be a technical success at the cost of business failure. Over promise and deliver late, but show great technical chops. Make sure that everyone in your market area sees how good your results are, even if they are not economically viable.

Go out of business. Be apologetic to your employees about failing. Tell them they did a great job and it's not their fault. It helps if you have a partner you can blame.

This is all OK, because you got the big salary, so you can buy a house and have a new car, etc. You also have the intangible asset of having a high profile start up with high technical visibility.

Do it again as many times as you can. If you do it right you will have some workers, clients, and even investors who will follow you around and experience the cycle multiple times. Your net worth can go up and you can become respected in your field without ever running a successful business. It's called failing up. It's a very popular career path in both Silicon Valley and Hollywood.

Git, Redmine, Jenkins

[gatkinso]

Coding standards: pick anything and stick with it. Use Google's. Why not? (Haha I note they are using svn.)

http://google-styleguide.googl...
https://google-styleguide.goog...

These types of decisions are many times arbitrary and one valid approach rarely is any better than another.

Class projects vs. professional projects

[Anonymous Brave Guy]

The pay cheque isn't the important thing. Experience working in a professional environment is. The difference between how you work on a class project and how you work in a professional environment is vast.

For example, class projects are typically:

- very small

- implemented by a single person or at most a very small team that does not change over the lifetime of the project

- finished within a short period of time

- built with unchanging requirements determined by a single authority and entirely known from the start

- implemented with little need or regard for ongoing maintenance.

Exactly none of those things will be true of a typical industrial software development project. The need to take these kinds of factors into consideration completely changes how you design your software, what tools you use, what processes you follow...

Re:Class projects vs. professional projects

[Anonymous Coward]

And that's only "for example"...

Dealing with a "team" in a school project and a "team" in a professional environment are two different things. Most of the complaints about "teams" in a classroom involve somebody not doing their share of the work or a lack of leadership. In the real world, that's often the least of the problems and anybody who's been around has worked on teams with worse problems.

I always find it funny when teachers talk about how group projects prepare people for working in the real world. While I do believe having some group projects are better than having none, it falls far short. Co-op programs are a better option for preparing students, although still limited due to short-term placements. A longer internship (proper internship, not getting coffee) of a longer duration is even better.

Group projects in school often give a false sense of "experience" or "competency" or "preparedness".

Re:Class projects vs. professional projects

[Hognoxious]

Some professional environments are distinctly amateurish.

Re:Class projects vs. professional projects

[Cragen]

Well, it's even "worse" than that. The group often has to define the goal and the requirements for the customer. If you have no experience leading a team or being a team member of a project that needs to be defined, the process detailed and agreed upon, etc., you are just a "coder", which is just the last and easiest part of the project.

Re:Class projects vs. professional projects

[g4sy]

this.

Re:My way or the highway

[Hognoxious]

make it a condition of their trail period.

If they do it wrong, tell them to hit the road.

Issues in general.

[hackus]

First, you my friend are going to have a mighty rough ride if you are thinking about competing against the new generation of software people coming down the pipe.

I do not know what advantage you think you have, but asking such basic and simple questions although not a crime, suggests you should not be the one owning the shop.

Hopefully you recognize that and put someone else in control because learning on the fly with investor money is a sure fire recipe for disaster. Unless you are funding the shop yourself.

The people I work with, never went to college. They are a new generation built upon Internet access. The are debt free. Free thinkers and horrifically skilled and on their second startup by the tender age of 23.

They are debt free, confident and not scared of failure.

More than a match for any CS program anywhere in the world. I would ask one of these young choppers to run the place.

That is if you can get enough respect from one of them by simply dangling your paper degrees in front of their faces to be the one they call boss.

Good luck, you are going to need it.

Wrting software != Selling software

[NewYork]

You need mutually exclusive skills. http://www.businessinsider.in/...

Real advice from someone who does this every day

[MooseMiester]

I own a digital interactive development house. The number of starry-eyed, exceptionally bright, highly motivated people who walk in our offices, or contact us, or are found by our marketing nets that match you would really surprise you. Some of the advice here is very good, a fair amount of it comes from well intentioned people who clearly have zero actual experience doing this stuff.

The bad news. Based on what you've said, you're going to fail. Why? Because you're made the same mistake 3/4 of the people who come to our door with similar ideas make... You have devoted all kinds of effort to the product, and hardly any effort to the acquisition strategy - e.g. How are you going to find people to buy this thing? If you're budget for product development is $500,000 then your acquisition budget should be at least $500.000. Today's marketplace is not "Field of Dreams", if you build it, they will not come.

Second, give up on the idea of finding a VC or angel investor. The occasional news story where some guy got a million dollars to build his idea are the exception, not the rule. I've sat in many VC presentations, and watched many entrepreneurs burn out in search of elusive funding. VC's give money to startups with 1 - 2 year track record showing positive cash flow - and what you give up, in return, is control over the company. Self funding is the rule, consider all of that money to be at 100% risk. Don't mortgage your house, get a small business loan, or count on free money from the government unless you are willing to lose everything you have if it doesn't fly.

Third, most software houses don't survive of a single product because most things are cyclical. So think about a product + professional services customizing the product. Or the product being sold outright (licensed user) or a monthly subscription model.

Fourth, people who make a living writing helpful advice websites on how to start your small business and run it... make their living telling other people what to do, not actually doing it. Take their advice with a grain of salt. Seek out real entrepreneurs who have actual businesses. A good place to meet these folks are at M&A seminars if you don't know any.

Fifth, do you love the work so much you're willing to work 12 hours or more a day for two, three years? Are you willing to give up vacations? How do you feel about being on call 24x7 365?

The good news: You can do this. I am not the smartest guy in the room, nor do I possess any magical powers. I too, started out as a developer, worked my way up the ranks, and am now the owner of a successful software business. I haven't had a "real job" with a boss and a paycheck in a long time.

My one piece of advice: Learn how to build relationships with people based on respect and trust. Build as large of a network of such people as you possibly can. Because, at the end of the day, it is honest, trustworthy, decent employees and partners that will make or break a business. Good software is NOT about technology, tools, etc. it is about good working relationships between people

lots of good ideas here

[mwaschkowski]

but it may be difficult to sift through them when what you are looking for is solid advice about the direction to go in and why certain actions/approaches will work, and others won't (or not as well). I've been building software for over a decade now and had my own business for about 7 years. I have learned an incredible amount from the experience of it. I can see from your question that there is going to be a process that you are going to have to go through. If you would like to have me consult with you for even a couple of hours, I might save you months of your life learning things the hard way... mwaschkowski at gmail.com Good luck! Mark

Draw a line in the sand

[rleibman]

My number one advice to anyone thinking about starting a business is to draw a line in the sand. Clearly state to yourself and others how much money you're willing to put into the business and how much time you're willing to spend. The DAY that you cross that line evaluate, if the business is not at that point successful, STOP spending money and call it quits. Number two advice. Don't be the only one spending money, if your business idea is not good enough to get someone (not in your family) interested enough to help you bank roll it, then it's not likely good enough to be worth it. Besides, with that you also get someone else who's vested into the success, and that person/group can help you find other resources you might need. But that's just generic business advice.. about software I have much more to say, but if you don't have those two then no matter how good you think your idea is you won't make it.

Don't listen to naysayers...here's my experience

[microTodd]

• Set up a VM server...Oracle Virtualbox is free. Run integration/platform testing and maybe even development on shared VMs. Don't be scared to spin up new VMs a lot for any reason
• Have a bug/task/defect tracking system. Either run bugzilla or JIRA or buy a cloud service like Atlassian's.
• Decide on source code control and use it. Either Mercurial or Git is probably your best choice nowadays. Host your own or pay the relatively cheap rate for a cloud service
• If your team is small, run your sprints in short spurts. When I have 2-4 person teams we do 1-week sprints. Daily standups are in a shared chatroom.
• Continuous integration. Automated nightly builds/unit/system tests with emailed reports to the team. Always be ready to ship.
• Don't skimp on your QC/test cycle...you'll hate yourself later when you have to pay down the technical debt. But in my experience new features/bulletpoints on the marketing slides sells more than the occasional bug takes away.

Play to your strengths. Be agile. React quickly to marketing changes. Some customer wants to buy but you don't do something? Promise it withing 6 weeks and then frickin' do it.

Good luck, dude. Its a fun and fulfilling endeavor.