Archive for the ‘software engineering’ Category

I came across an article posted a while ago by Rob Walling (http://www.softwarebyrob.com/articles/Software_Training_Sucks_Roll_it_Back.aspx) proposing that the best way to learn how to program is via an apprenticeship with a more experienced programmer.

I love the idea, it just sounds right to have someone shortcut you through a lot of the unnecessary pain. It is something that I have seen that could have been incredibly beneficial – especially when you consider just how many people there are working in the industry who are not up to scratch because of the "Here’s a piece of work. Now do it." mentality, which provides fresh developers with no guidance and assumes that people will simply pick up information as they need it. The problem is the lack of a feedback mechanism. No one to point out mistakes, challenge the existing design, discuss which parts are right, or point you to a shortcut.

There are two areas of the programming profession where working with someone senior could be beneficial:
- good practices. Not everyone out there knows about Code Complete, The Pragmatic Programmer et al. and the good stuff within. Having someone even point out the texts to you and help you to work through the ideas within makes a big difference. There’s good stuff there, and you can spot those who know versus those who don’t.

- conceptual versus practical real-world programming. Make a duck quack in different ways versus implement a web service that back-ends onto a 20 year old COBOL program with dubious documentation. It is the practical side of programming where an apprentice-journeyman relationship would make a huge difference. There is no substitute for experience, and learning from other people’s mistakes is a lot smarter than making them yourself.

It is not a substitute for higher education, which provides an important foundation in the field, but there is a gap between the goal of a degree which is to teach you concepts versus the practice of programming in industry. Rightly so. I would rather work with someone who understands concepts rather than someone who simply knows how to use technology X. You want people to be flexible and pick up new technologies as needed. The two should be combined in much the way that a medical student does an internship.

The natural question to ask is how you go about doing this in a deadline-driven environment, but I think this question is wrong one to be asking. Rather, how does the environment need to change to allow for this type of interaction to develop? You need an acknowledgement that the time of the both developers needs to be accounted for and set it aside. You cannot book 100% of a senior developer’s time on billable work and expect them to also coach a junior member of the team. Some companies do this type of thing incredibly well, but I would like to see this approach adopted more widely.

The biggest problem I’ve encountered in the past is something that sends shivers down the spine of most IT professionals – the dreaded question of how long a piece of work is going to take. I’m not talking about quoting for year long projects – they’re a whole different kettle of fish – but about the tasks that you have to do that are on the project plan. Software development is inherently dealing with unknown quantities – new technologies, unencountered bugs, changing requirements… the list seems to be unending. No two projects ever seem to be the same yet you are expected to give an accurate estimate every time. Even the meaning of the word changes depending on who is using it – programmer “best guess based on available understanding of the problem”, client/PM “fixed quote cast in concrete”.

The Software Engineering Profession has waxed lyrical on the topic for years, yet there is still no easily applicable model. Yes, there are tools such as function points and Cocomo, but they are no help for the most part. Heavy, complex, don’t take the nuances of the technology into account and they’re not really useful at the day-to-day scale of estimating. Is a web database system going to take the same amount of time to complete whether you use standalone JDBC, Spring templates, Hibernate or Ruby on Rails? Is it going to take the same amount of time to complete regardless of whether you are using the stable version of your favourite open-source package, or the new one with those brand new time-saving features you just have to use? No.

I approach the problem as per the XP boys. Implement a slice of functionality using the software stack, work out your “velocity” and extrapolate to a larger scale. In order to work out how long the work is taking I use a tool called ToDoList (http://www.abstractspoon.com/tdl_resources.html). Break down a task into it’s various steps and time how long each one takes. You can then base estimates of future work using the same technology by looking back on the task list for previous projects. It’s a variation on estimation
by experience, but slightly more formal since you’re not relying on memory. It would be interesting to see whether a larger resource that would let you see how long other people took to complete similar tasks would help, or whether it’s an inherently personal thing. My guess is the latter, which makes keeping a record of previous work all the more important. It’s not a panacea, but it will help.

Sometimes, through the drudgery and stress of software development we forget why we do what we do.