2 ms·

Daniel, Thank you very much for your reply. I got some great pointers from your article, and I look forward to chatting with the developers and casually bring

Daniel, Thank you very much for your reply. I got some great pointers from your article, and I look forward to chatting with the developers and casually bringing up some of the points you mention. I'm interested in your proposition - if they don't have an SVN repo and bug tracking systems they're not real developers. Are there any other very clear indicators that these aren't the guys you want on your team? Co-incidentally, if I do need to setup this kind of environment, do you have any recommendations on the software infrastructure I should use?

ErrantX 17y ago
I'll reply here as swombat has raised the point that struck me. My first question really WOULD be why are thye not using SVN. It could be they are: or perhaps using Git, Mercurial etc. (I would personally go with mercurial over anything else on a smaller team). Or it could be that as they work in an office together they have different methods of source control between themselves. Your first job is obviously to get some proper offsite SCM (I always recommend offsite for a small startup - that way you have a few guarantees. BitBucket (mercurial) give you one free private (hidden) repository [1] and GitHub (git) have fairly cheap plans for private repos [2]. Both of these integrate with most of the popular ticket / project management sites with little work. Swombat is right: if they dont have any kind of control going on with their code then your looking at some bad programmers. But I would say SCM discipline is easy enough to learn: so dont automatically give up on them. Find out what their preference is (if any) and work with them on a good workflow plan for how to get the code into SCM and how to checkout and develop it from there on a day ot day basis (a common problem we have here with SCM noobs is that they tend to forget to check in at the end of the day, for example, or at lunch. Eventually leading to all manner of pain!). As it's a small office it should be easy to manage though :) [1] http://bitbucket.org/plans/ http://bitbucket.org/plans/ [2] http://github.com/plans http://github.com/plans EDIT: as an addendum I would personally ignore all the comments about adopting Agile development practices (especially things like Scrum which was specifically mentioned). The major reason is that they simply do not work as well for you as they do for the people that "invented" the practice. Strict guidelines never work if you just implement them. Agile tends to be for teams that want to sound trendy and hip ;) it's faster just to develop your own process naturally. Also if you leap into the office with all these new "agile" ideas you'll just be considered "management type" and probably not be greeted well by the existing team. You obviously need to bring in stuff but in as relaxed a way as possible is probably best. As it is a small team it wont take long to have a few meetings to decide the way forward - and with so few members there is not likely to be long drawn out discussions. If you go in with some sensible stuff like SCM and workflow ideas and ask what they think of them you'l get a good response I'll bet. Oh - and outline your role to them as clearly as possible. They might, for example, think your beign brought in to assess them and get rid of them (which in a way might be true - but best not to say that :D) rather than to manage the product so they can get on and code. Hope that helps.
swombat 17y ago
I'm interested in your proposition - if they don't have an SVN repo and bug tracking systems they're not real developers. To clarify: I am not partial to SVN. My key point was that if they have no SCM whatsoever, they are not worth their salt. No sensible developer would develop any application with more than 1 developer without an SCM. Few sensible developers would even develop a 1-developer app without an SCM (unless it's really just a test app/prototype to be thrown away.. and even then...). I don't have any other major indicators, other than the ones in my article. With respect to software infrastructure, I'd recommend using hosted solutions (github, fogbugz, etc), whichever ones you find most useful for your project.

ErrantX 17y ago

I'll reply here as swombat has raised the point that struck me. My first question really WOULD be why are thye not using SVN. It could be they are: or perhaps using Git, Mercurial etc. (I would personally go with mercurial over anything else on a smaller team). Or it could be that as they work in an office together they have different methods of source control between themselves. Your first job is obviously to get some proper offsite SCM (I always recommend offsite for a small startup - that way you have a few guarantees. BitBucket (mercurial) give you one free private (hidden) repository [1] and GitHub (git) have fairly cheap plans for private repos [2]. Both of these integrate with most of the popular ticket / project management sites with little work. Swombat is right: if they dont have any kind of control going on with their code then your looking at some bad programmers. But I would say SCM discipline is easy enough to learn: so dont automatically give up on them. Find out what their preference is (if any) and work with them on a good workflow plan for how to get the code into SCM and how to checkout and develop it from there on a day ot day basis (a common problem we have here with SCM noobs is that they tend to forget to check in at the end of the day, for example, or at lunch. Eventually leading to all manner of pain!). As it's a small office it should be easy to manage though :) [1] http://bitbucket.org/plans/ http://bitbucket.org/plans/ [2] http://github.com/plans http://github.com/plans EDIT: as an addendum I would personally ignore all the comments about adopting Agile development practices (especially things like Scrum which was specifically mentioned). The major reason is that they simply do not work as well for you as they do for the people that "invented" the practice. Strict guidelines never work if you just implement them. Agile tends to be for teams that want to sound trendy and hip ;) it's faster just to develop your own process naturally. Also if you leap into the office with all these new "agile" ideas you'll just be considered "management type" and probably not be greeted well by the existing team. You obviously need to bring in stuff but in as relaxed a way as possible is probably best. As it is a small team it wont take long to have a few meetings to decide the way forward - and with so few members there is not likely to be long drawn out discussions. If you go in with some sensible stuff like SCM and workflow ideas and ask what they think of them you'l get a good response I'll bet. Oh - and outline your role to them as clearly as possible. They might, for example, think your beign brought in to assess them and get rid of them (which in a way might be true - but best not to say that :D) rather than to manage the product so they can get on and code. Hope that helps.

swombat 17y ago

I'm interested in your proposition - if they don't have an SVN repo and bug tracking systems they're not real developers. To clarify: I am not partial to SVN. My key point was that if they have no SCM whatsoever, they are not worth their salt. No sensible developer would develop any application with more than 1 developer without an SCM. Few sensible developers would even develop a 1-developer app without an SCM (unless it's really just a test app/prototype to be thrown away.. and even then...). I don't have any other major indicators, other than the ones in my article. With respect to software infrastructure, I'd recommend using hosted solutions (github, fogbugz, etc), whichever ones you find most useful for your project.