Developing on your own

Question

In my company each developer is given a project to work on his own, so there is hardly any teamwork. I've been building software like this, without the discipline of a good methodology of development, for a year. The results were ok but I would like to change and start using a more serious development approach for my next projects.

What would you consider the best practices to develop software on your own? What methodologies could I use in order to avoid common pitfalls in software development? What models of software development (waterfall -I'm joking-, extreme, agile, etc) are best suited for me?

I'd be very happy if you point me to some resources or tutorials where I could learn how to be a better developer :)

Thanks.

Answer 1

It's very hard developing software on your own, having another human being to bounce ideas off makes things so much easier / more satisfying. But, here's the kicker - that other person doesn't really have to be all that tuned in to what you're doing. Simply explaining things to somebody else often gives you insights into what you are doing.

I used to work with somebody that recommended "talking to teddy" - i.e. pick your favourite stuffed toy (Mr Binky), explain the ins and outs of that new RESTful API you are working on to Mr Binky. Slap your head as a blinding flash of inspiration hits you - "gah, I knew that I needed another resource in there, thanks Binkster!".

Mind you, I'm not sure of that colleagues sanity...

For a more reasoned approach, couldn't you form a loose alliance with another developer where you bounce your projects off each other, even if you then go back to working in isolation?

Answer 2

I think most "full-blown" development methodologies like xp and such are focused on channeling and streamlining communication between team-members.

If you develop in a "single-person" team, there is no benefit to be had in doing daily scrum-meetings and such with oneself ;-) Thus it should be enough if you stick to some best-practices like "use version control" etc. The books "Pragmatic Programmer" and "Ship it!" might give you a good overview over some practices worth adhering to, wether you work in a team or alone. At least the did it for me.

Just to be clear, you'll need some kind of structure or plan for your project BEFORE you start coding but something like a simple to-do list and a raw sketch of the planned software-design will do.

Answer 3

Do not fall into the trap of not documenting your code! that's, I think, one of the pieces of advice that is easily forgotten, because, hey you wrote the could yourself so you ought to know what it does, right?... wrong! just pick up one of your yesteryear projects and figure out how things worked without using any documentation whatsoever, it's like reading someone else (bad) code.

I always encourage myself to use a standard documentation style, like javadoc for java or the equivalent for .NET in code, but really any kind of documentation is better then none at all...

Answer 4

When i worked as a loan developer i use XP, coupled with Joel's getting things done when you're only a grunt article to keep me on the straight and narrow.

i treated it as a learning exercise that i could integrate into the team if i could prove that applying 'best practice' had a good ROI. which although is given for good developers is still something that needs to be proved; well at least in my experience.

Later i used a customised agile process which fitted better with the politics of the company i worked for.

Answer 5

If you feel that the practice is sub-optimal, and there are others who feel the same way, why not start co-operating a little? If your company is particularly weird and doesn't want to allow developers to learn from each other then I think you should be seriously considering alternative employment: you're probably not going to be the best you could be in such an environment.

Now that I've done suggesting you're asking the wrong question ;) there's a good starting point for solo developer agility on the C2 Wiki

Answer 6

A large part of most methodologies is actually defining how you can work together as a team. A large part of agile/extreme programming etc. is about communication, setting up your team-environment and more of that stuff. If you work alone some things are easier and some things (pair programming for example) are harder.

Try reading up on a couple of methodologies and pick practices that you think you need. If you're a one-man team you've got the luxury of being very flexible. So try not to give that up just to follow a methodology that's meant to make large teams work together. So only pick up the practices that you really need. Thins like TDD and working in iterations are the low hanging fruit. Just keep evaluating what you do and keep improving.

Answer 7

Use version control, always leave the day with the code compiling as a minimum, and always check in. I worked for many years in relative isolation in a larger organization, I naturally applied what is more commonly termed as Agile development practices. Get something working no matter how rough, the refactor, and repeat.

Maintaining a stable state helps a lot, it means when you can interact with someone you have something to demonstrate rather than a collection of ideas and abstract concepts.

I would agree "Pragmatic Programmer" is a great read.

Answer 8

@reefnet_alex

You're absolutely right - the process of articulating, even if it's to yourself or a stuffed toy, is wonderful for thinking things through. Personally, I type a blog-like monolog in a file when trying to work something out. This has the added bonus of being able to refer back to it when I need to.

As far as other strategies go, I find the best thing to do is to maintain a TODO list. If I get stuck on one thing, I just move onto something else on the todo list.

Answer 9

I've been working on my own for years. First as part of a group of mechanical engineers. Now on my own projects. I agree with the answers above:

Talk to somebody (anybody) about what you're working on. My wife's eyes quickly glaze over but she tries to ask clarifying questions. Usually the questions make no sense, but I pretend she's my boss and answer them anyways. I find all sorts of solutions that way.

Development methodologies are mostly overkill for a 1-person team. I've adopted a couple of agile practices though. First, estimate everything in small chunks of time no longer than half a day. Second, break your work into small "sprints" of three- or four-weeks. I use FogBugz for all of my estimating and scheduling (there's a free hosted version for 1-2 person groups).

Don't forget the essentials of code documentation, source control, and unit testing. I use Doxygen, Subversion/TortoiseSVN, and NUnit respectively.

Answer 10

@Kyle

The old explain it to yourself through notes in a file rouse eh? To my horror I saw this comment at the top of some of my old code the other day:

/*
    bloody hell - where to start...
*/

Answer 11

When you're the only guy working on a project/problem, the communication should be good, so formalities are not really necessary for that. However, as mentioned in other posts, good practices such as version control still apply. Bouncing ideas off of somebody has proven critical for me too.

Though communication is not a problem when working alone, I have found it helpful in some cases to use post-it's and make a personal scrum board. I just recently moved from a company that was team-oriented to one that is far from it, and it is a difficult transition.

Just another thought along the lines of how to come to solution... the book Conceptual Blockbusting has some good observations on how to better problem solve.

Answer 12

Thank you very much for your tips:

• I try to document my code as much as I can, using common standards. I try to think of the poor guy who maybe someday will come and have to maintain my code (who knows, maybe that guy could be me!).

• I use source control. That's a must for me and I just can't work without it.

• Unit testing (isn't this the third pilar?)... Well... I don't do any unit testing at all :(, and that's one of the things I'd like to change for future projects.

• When I design I try to take notes of all my internal thoughts (it's more or less like talking to your teddy, isn't it?).

• I also have a TODO list. I wonder if there is some application (or web application) to better monitorize all these tasks.

I'll take a look to some of the modern methodologies and try to incorporate some techniques to my own methodology. This seems really interesting.

Now I'm also thinking of installing Cruise Control in my machine, but would it be really worth for me?

Answer 13

Check out The Joel Test. Implementing these practices as an independent developer has been a rewarding challenge.

Answer 14

I've asked a similar question before, you might find some good answers there.

Answer 15

I'd suggest that as well as using SCM, use an issue tracker. Even though you may wind up spending a little more time adding in things that need to be done, it provides a concrete record of your progress, in an easier to follow format than the changelogs from your revision control.

It also gives you warm fuzzies when you cross things off your list. I see it as an extension to a TODO list.

Answer 16

Personal Software Process

Answer 17

Seems like you have the code part under control, but just because you're the only developer, you need to manage how you are working with users, management, network admins, etc. I'm the only programmer at our firm, but constantly interact with others on given projects. They are probably more interested in documentation, requirements gathering, testing & debugging.