Slashdot Mirror
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.
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.
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.
Because you won't be employing too may people in the West...
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.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
As a startup, you need to do whatever it takes to get off the ground first, even if it means accruing some technical debt. There are no points awarded for going bankrupt with a perfectly clean code base and architecture. Much like the financial debt, you of course want to minimize technical debt as much as possible and manage the that you accrue.
The core practice I would recommend that you adhere to insofar as possible is to scrupulously maintain unit tests with at least 85% block coverage AND 85% branch coverage, which will let you add features and expand without fear. Coding standards are nice to have so that new team members can ramp up quickly as you expand.
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.
As if you are the one who maintains it.
There was an unknown error in the submission.
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.
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.
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.
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.
Don't fight for your country, if your country does not fight for you.
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.
$5 / month hosted VPS on linux = awesome!
...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.
[FUCK BETA]
People have already said it, but it's worth repeating. You MUST have a strong approach to sales and marketing. Problem is, this whole idea is usually anathema to engineering types (developers included). From my perspective, I'd rather be locked in a room to fight off a bunch of ebola carrying mosquitos whilst blindfolded than spend five minutes in a meeting with an effective salesman. The fact of the matter is, however, they are important and valuable. I don't generally care for them on a social level, but I respect the work that they do (if they're ethical). I've had a very lucrative career over the decades and I owe a great deal of that success to working along time with strong salespeople.
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.
-- In the beginning was the WORD, and the WORD was UNSIGNED, and the main(){} was without form and void...
No overhead, no business cards, all verbal, all word of mouth, all cash. And no questions asked. It's the only way.
Get an entry level job at a startup that is small enough for you to network with entrepreneurs. The idea is that the next company they startup involves your product ideas, if they are market viable. Then you become a business owner with partners who are already proven. I say this approach is good for you because you seem clearly not ready to go at this by yourself, but your interest in ownership can be satisfied this way. When your first startup succeeds, you will be in a better position to command your next startup under favorable terms.
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.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
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.
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!
There's an interesting video about software shop culture from Spotify: https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
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.
This assumes you are based in the US although the low level items might well work anywhere.
Each individual will cost you 150% of their base salary. More with paid vacations and health care. Plan ahead. Check out what it takes to pay for unemployment if you lay off workers. It can and will break a small company. Software will allow you to shift that burden to the worker. Pay them as sub-contractors, you pay them more so it doesn't save a lot of money but it does make planning easier. Beware that is fraught with legal ramifications if they don't operate as a sub-contractor.
To make a profit requires five programmers to support one office worker. Keep your office small until you can afford to expand. Yes, that means you will be doing everything by yourself.
Pay your taxes, pay yourself a salary - do NOT draw cash from the business and do not falter.
For software issues, if a programmer doesn't stick to the coding standard fire them. Immediately. Better yet, make it a condition of their trail period. The cornerstone of a software business is being able to maintain their own code. A lazy, self-absorbed or just plain bad programmer will negate the best intentions. The first sign of that is refusal to support the coding standard.
Team code reviews are a bother, it is better to use static analysis and coding standards. 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. As they grow in their abilities you can review their code at a higher level. If you do use team style code reviews and a senior programmer rips others apart invite them into your office and return the favor. If the behavior doesn't change to constructive then get rid of them.
Build teams. The worst thing about modern software practices is Suits (aka MBAs) deciding that software programmers/engineers are replaceable units. A good team will out produce the same number of individual programmers.
Good Luck.
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.
Hey KID! Yeah you, get the fuck off my lawn!
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.
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.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
Since it is obvious that you don't know how to move into this new venture, you would be wise to either (1) hire some one to do this for you--a manager, etc. or (2) start working for a software house and learn how to do this. There are probably other options but my business training only regurgitates these two.
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.
Browsing at +1 - no ACs, I ignore their posts. So refreshing!
Best practices will emerge as a natural byproduct of your team and their dynamics. Your number one issue will be finding the right team. In my experience, hiring has been the most difficult aspect of running a software company.
Besides hiring, you need to find a good accountant and a good lawyer.
Until you have that, your focus on tools, standards, etc are premature.
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.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
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.
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. No matter what language you're going to use, make sure you enforce good best practices from the get go. This will make the job of the junior programmers much easier and enable them to be more productive.
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.
Tat Tvam Asi
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.
Live today, because you never know what tomorrow brings
Sounds like thats a consultancy company.
I've only ever founded product companies.
Here's how we did it.
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....
- 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.
The difference between Canada and the USA is that in Canada healthcare is a right and gun ownership is a privilege.
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.
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.
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.
Then HVAC. Then rapper. Then (real) ganster. That's about all the good ones. Avoid politics, law, and medicine. Everything else is a "settle for". Oh, you have already settled? I can see your problem/point - stuffed full of academics but zero places to pull that stuff out. It doesn't matter that you want to avoid outsourced source; it only matters what the hittites in Romania, Vietnam, Cambodia, Thailand, Burman, India, Bangladesh sell for (maybe your 'future stuff' in the first place).
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, 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!
We suffer more in our imagination than in reality. - Seneca
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 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.
I do not fail; I succeed at finding out what does not work.
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.
http://saveie6.com/
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.
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.
Oh, say can you see by the dawn's early light
What so proudly we hailed at the twilight's last gleaming?
Whose broad stripes and bright stars thru the perilous fight,
O'er the ramparts we watched were so gallantly streaming?
And the rocket's red glare, the bombs bursting in air,
Gave proof through the night that our flag was still there.
Oh, say does that star-spangled banner yet wave
O'er the land of the free and the home of the brave?
On the shore, dimly seen through the mists of the deep,
Where the foe's haughty host in dread silence reposes,
What is that which the breeze, o'er the towering steep,
As it fitfully blows, half conceals, half discloses?
Now it catches the gleam of the morning's first beam,
In full glory reflected now shines in the stream:
'Tis the star-spangled banner! Oh long may it wave
O'er the land of the free and the home of the brave!
And where is that band who so vauntingly swore
That the havoc of war and the battle's confusion,
A home and a country should leave us no more!
Their blood has washed out their foul footsteps' pollution.
No refuge could save the hireling and slave
From the terror of flight, or the gloom of the grave:
And the star-spangled banner in triumph doth wave
O'er the land of the free and the home of the brave!
Oh! thus be it ever, when freemen shall stand
Between their loved home and the war's desolation!
Blest with victory and peace, may the heav'n rescued land
Praise the Power that hath made and preserved us a nation.
Then conquer we must, when our cause it is just,
And this be our motto: "In God is our trust."
And the star-spangled banner in triumph shall wave
O'er the land of the free and the home of the brave!
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.
You can't handle the truth.
Forget it. Any software of any value you will ever develop will be pirated and downloaded for free. If you by chance ever build some sort of killer app, a bigger software company will sue you for plagiarism and run you into the ground with legal expenses. You will have to surrender your intellectual property and lose everything you have. The golden days of software development are long gone.
You're seriously asking sound business advice from a bunch of nerds who have never done anything practical in their lives and never will? Ask real, successful businessmen. Ask real people. Smelly neckbeards who jerk off to lolicons and tentacle porn are not the kind of people you want to listen to. Unless you're one of them yourself, of course, and in that case you have no place in business or even the civilized world.
With your level of experience, you are need to hire a good team lead or architect:
Agile vs waterfall? well, I have never seen anyone really do waterfall. It just can not work for designing software. Every claimed waterfall deployment in the real world ends up being iterative, since it actually software actually isn't built that way. Agile? well it depends. If your basic infrastructure and processes are good, and your developers are competent and commit to deliver, and hit their sprint targets, go for it. If they need more management, or your basic processes are not mature, I'd hold off, and roll it out more slowly (that's not to say, that it isn't a good idea)
I don't think you really need coding standards as such. There should be a consistent style for your code base, and developers should be aware of it. You can use tools like astyle to enforce, if required.
I wouldn't contract anything to begin with. It is difficult to ensure quality, and you will need to review contracted code internally. I would hire only senior or mid level developers to begin with. You don't have the resources to train the inexperienced.
I'd start with one product, not a whole product line. It will be tough enough.
You will need to minimal infrastructure to get started - I'll give you some background, particularly on the source control side, where I have a lot of experience handling migrations, have evaluated virtually everything, and have seen some of the terrible creations of the past:
- Get a good bug tracking system (eg. Fogbugz, Jira, Mantis, Bugzilla).
- Institute code reviews. Inspection is good for removing bugs early.
- build / delivery infrastructure - you build system will need to be able to build your product, and create an installer in a single step. engineering the build system is the first step. You will need CI or nightly builds. Look at using jenkins or similar as a scheduler for your CI builds.
- Use a modern source control system that supports light weight branch per-task. Branch per-task is recognised best practice (do not listen to anyone who disagrees - they probably have a tool that does it badly!). Branch-per-task isolates developer changes from each other, minimises integration issues, and allows controlled, agile, and flexible delivery.
Look at git (or plasticscm if you need something commercial) Git has a steep learning curve, but if you contract out the hosting (eg. github), the most difficult part - managing upstreams + security is pretty transparent. Most competent developers will also be familiar with Git. PlasticSCM is really usable and nice, and the core merge system is excellent. The only downside is that it the client is still a little buggy, particularly on Linux, but support is good. Saying that, I have never seen plasticscm destroy code. I _have_ seen perforce repo corruption several times, on good reliable, and redundant hardware. Plastic also uses your choice of database backend, so it also has better supporting maintenance tools for the data. Git has redundancy built-in, due to its distributed nature.
Avoid legacy source control systems like clearcase & perforce. They are vile, vile, vile. clearcase can branch/merge reasonably well (without some of the intellgence of modern systems), but it is slow, complex, and has a file centric model. Development is also dead, and support non-existent - the worst I have ever seen [or not seen!]. The UCM part is even more complex, but has limited non-atomic changesets, and when someone makes a mess, requires hours of removing hlinks, and other esotoric references, completely manually. Clearcase multisite is super expensive, and doesn't actually work as you would expect - it just ships delta packs on a sceduler - no instant updates! It comes from the era when multi-site, meant people posting tapes in the mail. Perforce branching/merging and usability are a nightmare compared to a modern system, and the branching model is insane. Nobody with any sense would make a new Perforce deployment. Technology has moved on by 20 years from havi
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:
Free, as in your money being freed from the confines of your account.
It also depends on what type of software you want to write. What industry(ies) are you targeting? I work in the medical software arena. If you don't have proper documentation, coding standards and testing methodologies, you won't win any business.
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.
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.
I am very small, utmostly microscopic.
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.
Why is Snark Required?
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.
I am very small, utmostly microscopic.
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...
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Your limiting factor is not accountants, or lawyers, or marketing.. it's clients, talent, and finished product.
Software has unfortunate aspect that, if people will pay, they pay nothing until primary features are mostly done, and business model is clear. It is hard to make a working product and sell it.
My suggestion, skip the lawyers, accountants, and marketers, save your money for a good lead software dev, until it's clear you have the full solution. Only when you actually have a few clients, then accountant.
... and I came out disilusioned with the idea of running my own business. In my case, I am actually a software developer with tons of experience in the area where I was operating.
1) Health Care: I have since left the US so I am not sure how things work now. But when I was living in the US, leaving a good paying corporate job with health benefits is a scary decision. If you are young and healthy, you can take the risk. If you have a family though, you are also risking their lives. What if one of your kids gets really sick? Illness was the number one cause of bankrupcy filings for the middle class when I left the US. I would never risk running my own business unless I was living (as I do now) in a country that offers universal health care.
2) Taxes: Dealing with taxes is a nightmare. We are accostumed to things that are either black or white but tax law is very vague. A lot of it is based on interpretation and good accountants know how to explore the loopholes. The problem is that, at the end of the day, you are responsible for the taxes of your company so you better understand what the accoutant is doing on your behalf. In my experience, most businesses are not really following tax law precisely. The owners do not understand that or they choose to ignore it because they feel the accountant has their back (or this is what everybody does so it is fine for me to do it as well). Try to explain that when you get audited.
2) Do not hire anyone... at least not until your business is looking really strong and there is a steady flow of money coming in. The minute you hire someone, you will have to deal with more regulations and taxes than you could ever imagine.
3) So you have cleared all the hurdles and you are now running a succesfull start-up. Congratulations! You are now the prime target of a patent troll. You probably do not have enough cash to fight them in court and they know it. You will have that to worry about as well.
So my advice is ... don't do it. It ain't worth it.
I was in your shoes a couple of years back, yes I do have a Masters in CS and around 10 years of development experience in various tools and languages. First, how are you getting paid? Do you have funding lined up? If your answer to that question is to dip into your savings or your retirement plan, then that is a big no-no. If your answer is to do things without getting paid, then you cannot possibly hire anyone. Software contracts are very difficult to procure and sustain, with outsourcing being the norm, and our immigration system making more visa's available each year, things are going to get difficult from here. Large companies do not follow quality and rather plan for the year with the funding they get. Good luck to you, but i would look at other business opportunities.
Find onlin your local jurisdiction's labour laws. They will exist online and you will be able to read and understand them. Read them and understand them. From the beginning start treating your employees professionally and properly.
If they do it wrong, tell them to hit the road.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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.
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
Somebody somewhere will have a patent that you'll be infringing. Fuck it would be my advice, you can't compete in a rigged market.
--
roman_mir
And I'm thinking about doing it again. The reason I got out was that getting health insurance was starting to take over, so I'm hoping that Obamacare lasts & helps all kinds of small shop owners with the kind of help I needed then. Also: I was going to have to charge for some proposals of moderate complexity, because I couldn't afford to give that much time away to tire kickers. Most of all, I was beginning to annoy myself with the frequent lunch invitations I was extending. I just can't live with the consequences of eating a lot of big lunches.
You need an accountant to assign you your housekeeping tasks, and perhaps for some help around tax time, but this is more like buying several hours of consulting a year, than hiring a person.
You should have a standard time and materials contract, if that's the kind of business you plan on doing. But I would consider this an alternative to on site consulting. If you're a one guy shop, it's OK to ask the client to indemnify errors & omissions, if need be. Make sure that you keep your specifications precise and your iterations rapid, so your bills are small and frequent.
Most of all: you should have a reason for being. A software package to maintain and a way to get it to your marketplace --- and knowing what that is --- is the trickiest part. Knowing when you got this wrong is the most important part. This software line you speak of: why is it worth paying for? How does it stack up against available solutions? Be realistic about how a lack of professional software development exposure might really mean that you need to do quite a bit of research about your market prospects, and getting this right is beyond critically important.
And about gaining more professional exposure: why miss out on that? If you start up your own shop, you'll have so many tasks that will present even greater obstacles to your gaining that experience. Why not let someone else pay you to make your rookie mistakes?
Remember: Your most valuable asset is your ability to make a living, so don't gamble it away unless you have a reasonably solid expectation of a rapid and warm welcome in the market.
You need mutually exclusive skills. http://www.businessinsider.in/...
Casteism
Essential infrastructure you need to put in place - where infrastructure is people and/or software tools.
1. Project Management. What you are going to deliver when. Who is working on what.
2. Customer services. Trouble ticket management, support requests & escalations.
3. Source control, deployment and automated testing. Automate everything. From the outset. The upfront investment will save you a fortune.
4. Documentation. Whether it's self-documenting code (i.e. extracting comments and functions from code), a wiki, scans or photos of whiteboards doesn't matter - but you will need this to scale. (And possibly even remember yourself why you made certain design decisions along the way).
5. Telephony, Email, CRM. You need to track the conversations you have with sales prospects, actual customers, and everything in between. This is non trivial as soon as you have more than a handful of customers.
6. Sales & Marketing. As others have said, you are nothing without customers. Build a co-operative relationship with your first clients; use their feedback to build a better product. Do not bullshit them - be honest about what you can do and what you are planning to do. If you commit to a schedule, keep to it - it will build trust. Hire a sales person - make that your first hire. Support the sales person with sales scripts and the ability to demo as real a product as you have available - slideware is dead, powerpoint is dead if you want to close a sale.
7. Payment infrastructure. Cash is king. If you can persuade your clients to pay up front, you will be in a much better place. Automating payment collection is essential. Most modern accounts systems will do this for you - you don't need to build an ecommerce portal (and that may not be appropriate anyway, depending on your product).
8. Allow 2-3x the money and 2-3x the time you anticipated to achieve your 'realistic' plan. Deliver an incremental product - shipping means customers, means feedback, means better product iteratively...
Source: a reasonably successful SaaS startup, bootstrapped over a 5 year timeframe.
... unfortunately there is no "right" answer. I have 12+ years of experience plus I am writing on this topic for my master's thesis, so at least I hope I haven't just _missed_ the formula somewhere.
From a coding point of view: Study best practices. Work quality and maintainability into your code while it is young. Otherwise, you may hit your first release, but it'll get much harder from then on out. If you are busy making changes and fixing bugs, you do not have time to innovate.
From a team point of view: Get the best people you can afford and that can work in a team. A rockstar developer can be 10 times more productive than an average developer (I have heard, and I believe). However, think of the "Sheldon" consequence: if he cannot work on a team, then he is a detriment. Don't worry about titles and roles because a good team will work itself out. Keep your team as small as possible while still meeting the needs of development.
From a marketing point of view: Everyone in your company is a marketer. Remember your brand. Live your brand. Use personas to guide your development efforts.
From a leadership point of view: A strong leader is vital to the performance of the company. They should provide motivation, encouragement, and understanding. They should also know when to get out of the way and let the team work. Never force culture. Nurture the culture you want through hiring and through living it.
These are only a few highlights. I hope write more on this topic on my blog at some point. (yes, shameless self promotion) http://dphunct.tumblr.com
-dam
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
Murphy was an optimist
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
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.
It doesn't look like you're asking the right questions.
To _start_ a product line, you need product and more importantly, customers.
And permission from your current employer to use whatever ides you have in your head.
If you're still thinking about hiring people to any of this done, find your local business development organization (google, or ask your chamber of commerce), and take every introductory session they have. Running a business involves talking to people, and this cannot be learned from just reading books or blogs. If the only value you bring to the table is the original idea, then you will not be happy with the outcome, nor will anyone stay happy working for you.
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.
"You cannot find out which view is the right one by science in the ordinary sense." - C.S. Lewis on Intelligent Design