Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Businesses Software

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

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.
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • First and foremost (Score:5, Insightful)

    by vivaoporto ( 1064484 ) on Saturday November 22, 2014 @06:31PM (#48441389)
    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.
    • by Nuitari The Wiz ( 1123889 ) on Saturday November 22, 2014 @06:57PM (#48441529)

      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.

    • 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

      • by JWSmythe ( 446288 ) <jwsmytheNO@SPAMjwsmythe.com> on Saturday November 22, 2014 @08:07PM (#48441791) Homepage Journal

        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.

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

          • by Anonymous Brave Guy ( 457657 ) on Sunday November 23, 2014 @10:15AM (#48443647)

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

            • Some professional environments are distinctly amateurish.

          • by gatkinso ( 15975 )

            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 resour

          • by unrtst ( 777550 )

            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

          • Why is a pay check important?

            Eating is kind of important.
        • by Euler ( 31942 )

          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 expectat

          • 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 bl

            • by Euler ( 31942 )

              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.

        • 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

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

    • by American AC in Paris ( 230456 ) on Saturday November 22, 2014 @07:25PM (#48441643) Homepage
      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.
      • by drooling-dog ( 189103 ) on Sunday November 23, 2014 @12:25AM (#48442573)

        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.

    • by Anonymous Coward

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

      • 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.
    • by rtb61 ( 674572 ) on Saturday November 22, 2014 @08:05PM (#48441779) Homepage

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

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

        • by rtb61 ( 674572 )

          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 infrastru

  • by BarbaraHudson ( 3785311 ) <barbarahudson@gmai l . c om> on Saturday November 22, 2014 @06:41PM (#48441441) Journal

    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.

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

      • Re:Mod parent up. (Score:4, Insightful)

        by rasmusbr ( 2186518 ) on Saturday November 22, 2014 @07:15PM (#48441599)

        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!

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

        • 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?

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

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

    • by wlj ( 204164 )

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

  • As if you are the one who maintains it.

    • 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!

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

  • by Kohath ( 38547 ) on Saturday November 22, 2014 @06:48PM (#48441481)

    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.

    • by 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

      • by Kohath ( 38547 )

        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.

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

      • by Kohath ( 38547 )

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

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

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

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

          • by muridae ( 966931 )

            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 t

  • 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.
    • by raymorris ( 2726007 ) on Saturday November 22, 2014 @11:08PM (#48442357) Journal

      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.

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

  • If you are planning to sell software to the government or business as a startup, consider source code escrow [wikipedia.org]. 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 custom
  • ...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.
    • 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.

  • 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 t

  • 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 p

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

  • by Zurk ( 37028 ) <zurktech.gmail@com> on Saturday November 22, 2014 @07:43PM (#48441693) Journal

    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.

  • by wvmarle ( 1070040 ) on Saturday November 22, 2014 @07:45PM (#48441699)

    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!

    • 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.
    • by muridae ( 966931 )

      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 everyo

      • 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 per

        • by muridae ( 966931 )

          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

  • by 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/

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

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

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

  • 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

  • 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.
  • 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 flexibl
  • 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 custom

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

  • Just read Getting Real [37signals.com]. 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 t

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

  • 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 wi

  • 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 th

  • 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 foremos

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

  • 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 wor

  • 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 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 pa

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

    http://google-styleguide.googl... [googlecode.com]
    https://google-styleguide.goog... [googlecode.com]

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

  • 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 enou
    • 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 spurt

3500 Calories = 1 Food Pound

Working...