This week I was going to try and finish off some development work, whilst also starting on a variety of things that need to be done in preparation for the impending set-up of my company. That has got me into setting up a business-only line on a VOIP/SIP phone, putting a proper multi-user e-mail system in place, and setting up some new domain names with holding pages, web/email-forwarding and the like, as well as starting to look into a number of potential suppliers for various other services I’ll need.
So there has been plenty of fun and frustration learning the ins-and-outs of DNS records, fiddling with SIP-phone configuration, and seeing just what “virtual office” services are available these days and which combination of things might best meet my needs. As usual, everything takes longer than it ought to. You set things up, test things, puzzle over what doesn’t work, figure out what to do, re-configure and re-test everything, document it all for future reference – and suddenly a whole day has gone by and it’s very dark outside.
In the end I didn’t get very far with the development work. I looked at it a couple of times, but with all the other stuff going on I was pretty much just staring at the screen. So the first half of the week turned into being a complete break from coding (more accurately, from writing Javadoc and test cases), and I only got back into proper development work towards the end of the week once the other stuff had calmed down a bit.
This has been a big reminder of how hard it can be to mix actual system development, and especially programming, with anything else. I can juggle lots of non-programming tasks when not programming, but mixing anything else with programming just seems to slow me down on both sets of tasks and leave me feeling drained. Except, perhaps, for technical reading and learning new stuff, which I always seem to be able to do in parallel with anything (regardless of whether it’s directly related to current work or not). I suspect everyone has different abilities and thresholds on this, but for me that’s just the way it is.
So I think from here on I’m going to set myself a fairly rigid routine of spending a fixed amount of time at the start of each day for non-development tasks, and then try to completely forget about that and spend the rest of the day on development work. For now that will mean an hour each day for non-development tasks, but that will increase as the development work winds down and other things build up.
From a broader perspective, this has also been a reminder of how different this current project is from anything I’ve ever worked on before. Specifically, due to doing the whole thing on my own, rather than being part of a team that is itself part of a larger organisation (or even being a one-person project within a larger organisation). OK, strictly speaking even this project isn’t really just me on my own, depending on where you draw its boundary – there are companies supplying me with services, emotional support from friends and family, various sources of advice, and assorted background chatter from the internet. But it’s as near to being a one-person project as anything could ever be.
There are pros and cons to this, and often they are two sides of the same coin:
- You greatly reduce and simplify the management, planning and tracking that is necessary, but don’t have anyone to haul things back in if they start sliding off track.
- You completely cut out all the usual communication overheads, misunderstandings and conflicts, but don’t have anyone to discuss ideas or problems with, nor anyone to tell you when you’re wrong.
- You don’t have other departments imposing pointless procedures, meetings, negotiations, delays etc, but whatever needs doing you have to figure it out and tackle it yourself rather than having appropriate experts on hand to do it for you.
- You have pretty much complete control over everything, but you can’t actually do anything in parallel unless there’s built-in “waiting” time involved (i.e. it’s just like multi-threading on a single processor).
- Everyone is always pulling in the same direction (at least in overall terms – I still argue a lot with myself over details), but the entire responsibility for everything is on your own shoulders.
Depending on the overall circumstances, a self-contained one-person project can also potentially cut out or vastly reduce a whole raft of tasks, overheads, risks and other issues that arise when creating and sustaining a team of people. Office space and facilities, recruitment, internal politics, rules and regulations, team dynamics, quality control – the list goes on and on. Not to mention the costs involved and all the issues this brings up over funding.
Overall, I think software development by a single person working entirely alone and independently can be extremely efficient, for the right person on the right project, but at the cost of things sometimes taking a long time to complete. That isn’t the contradiction it might appear to be. For example, suppose an individual working alone can do something with a quarter of the total effort that an eight-person team in a larger organisation would have to expend (taking into account all of the pros and cons of each approach, including the broader range of skills and aptitudes the bigger team could bring to bear). Then the individual would still take twice as long to complete the work, albeit at a very much lower cost and with a much “simpler” project.
Of course, there are lots of other issues involved, not least of which are the complete dependence on a single person, how much a single individual can realistically tackle, what happens after such a development project is finished, and what kind of sales, marketing or support effort might be necessary for the resulting product. So in most cases having a single individual doing everything on their own simply isn’t feasible or acceptable. But when it is possible, the costs and overheads that it can cut out can be quite staggering.
I suspect the ideal is a one-person team within a suitably-supportive larger organisation (if such things actually exist), together with an appropriate deputy or understudy. Or maybe we still need the kind of “surgical team” suggested in Brooks’ famous book The Mythical Man-Month.