Current Articles | RSS Feed RSS Feed

Stick your con call up your estimate! 6 things you can skip to save time in a software project

Posted by Andy Singleton on Tue, Apr 21, 2009


The definition of higher productivity is doing less work to get the same result. Maybe that's why most of the feedback on my recent podcast was about the list of "don'ts" - things that you can cut out of a software project to save time.  Or maybe people just found some of this advice surprising.  Let's count down the greatest hits.

6) Travel

Traveling takes a lot of time.  You might think that it's going to speed up your project by bringing different parts of your team together. However, if you know how to manage a distributed team, it's actually a lot faster just to sit down wherever you are and get the work done.

5)  Architect in advance

Agile gurus recommend that you design "as late as possible" - ALAP - meaning that you wait until you need to implement something before you add it to your architecture.  But, most engineers find it unsettling to start a big project without an architecture to match.  Even the people who say they like ALAP often don't really practice it (sort of like pair programming).  But, the reasoning behind the ALAP idea is very sound.  If you wait to do something, you might never have to do it.  The project might go in a different direction, or be canceled, or be great in a simpler form, or you might figure out a better way to do it.  The work you didn't do is 100% time savings.

4) Add project managers

We all know that bigger teams are slower.  According to the statistics in the big fat book "Software Assessments and Best Practices" from Capers Jones, my favorite bedtime reading, programmers are not responsible for this problem.  Actually, teams get slower when you add project managers.

3)  Conference call

I have noticed something when we go to "rescue" a project.  If the team spends a lot of time on conference calls, the project is probably delayed.  Maybe the delay causes the phone time.  All I know is that conference call time is closely correlated with project failure.  It's best to avoid conference calls.  You should write down your tasks in tickets, hold a quick stand-up meeting, and maybe keep a chat thread running.  If you start setting up conference calls, your people will be bored, and you might get sucked into a time warp.  In the two years since I started making this claim, I have never heard someone say "I worked on this project with a lot of conference calls, and it went great!"  This never happens.  Prove me wrong, I dare you.

2) Interview

It takes a long time set up job interviews, and some time to do them.  If you go straight from a resume to a paid trial task, you get to the work more quickly.  You might also get better results.  Job interviews are deceptive.  You might think you are hiring someone because they proved they can do a good job, but statistically, about half of the time, they are just good at interviews, or they matched some preconceived notion that you had about what a good person would look like.  That's why orchestras often hold auditions behind a screen.  Try trials.

1) Estimate

A lot of technology, skill, and time goes into estimating how long things will take.  In many cases, this expenditure of time and treasure is useless.  Maybe you can skip the estimates, and get your real work done faster, or take the time that you save and do something equally useless on Facebook or Twitter. Let's look at the cases where the time estimate is useless:

  • You already know what order you are going to do things in, and no estimate is going to change that.  This is the big escape route.  If you can get things into priority order, with a good roadmap, you will not need to estimate.
  • You already know how much time and money you are willing to spend on the project.  This is the typical reality.  It doesn't matter what your estimate comes to.  The project is worth a certain amount of time and money.  As an entrepreneur, I totally sympathize with this time-boxing money-boxing approach, and I recommend it.  Given a new product idea, I am perfectly happy to say that it should take X weeks to build and not more.  A bigger organization might pretend that they care about how long you think it SHOULD take, but most of the time, they are lying to make you feel better, or self delusional.  You can deal with this by using the agile method of prioritizing, and always having something that you can ship, however incomplete.

  • The estimate is going to be wrong anyway.  There are ways to improve estimates (reduction to detail, self-estimates, historical velocity, etc.)  However, some projects have a lot of dependencies and undertainty, and over a certain size of project, the estimates are almost always wrong.  You can use the tactic of tracking your estimates and comparing them to actual velocity.  If the estimates get better with this technique, then keep doing it.  If they keep going off track, then maybe it's best to give up, and just prioritize better.
Task scheduling is a worse time waster than estimating. You can learn to estimate correctly, but you always do things in a different order than the schedule.  Then, you have to spend time fixing the schedule to match reality. That is why we schedule by stacking a bunch of tasks (not ordered or scheduled) to be done before a milestone date.  That way, you can do them in any order, and you don't have to spend time fixing the schedule.


Now that I am at it, there's more.  These aren't tasks to skip, but rather, situations to avoid altogether.

Do anything with a fixed specification

You may feel like a winner when you purchase services using a fixed specification, but if getting to a spec takes longer than doing the services,  you lose.

Divide work geographically

It might seem like clever management, a nice simplification of roles, to send your requirements to Chicago, your coding to Bangalore, and your testing to Lima.  I think this wastes talent and makes your life harder.  Why not hire people in all of your locations that can handle the complete process?

Use synchronous collaboration (phone, video, screen sharing) to manage fast-moving situations

It's the job of a good manager to avoid fire drills, emergencies, and any type of fast-moving situation.  People should have enough time to do good work.



Tags: , , ,


Where can I find that podcast you mentioned?

posted @ Wednesday, April 22, 2009 6:03 AM by Gerhard

This is post contains things which everybody knows. It useless for me.

posted @ Wednesday, April 22, 2009 6:36 AM by cranfan

Hi! good article on some good practices for agile, I specially agree with 1 and 5. 
Alberto G

posted @ Wednesday, April 22, 2009 10:26 AM by Alberto G

Good post. There is special system for time and project management - TimeLine, here: <a>

posted @ Wednesday, April 22, 2009 9:51 PM by megauser

You are crazy.

posted @ Thursday, April 23, 2009 9:44 AM by Mirko

6) Travel 
Partially agree. Sometimes you need to sit down face to face with high level stakeholders or vendors. Typically you would not want to negotiate a multi-million dollar contract purely over e-mail and phone.  
5) Architect in advance 
"The project might go in a different direction, or be canceled,..." - sure and the reason why it went in a different direction or was cancelled could be because you didn't architect it to begin with. I think there is a lot of middle ground here.  
4) Add project managers 
If you are not saying that you can do without project managers at all, then I mostly agree. PMs are needed to crack the whip, communicate with stakeholders, plan a budget, ensure things are on track, etc. This is why you, Andy, are around :) 
3) Conference call 
Can't resists, but to play a "devil's advocate" here. If you have a distributed team and you want to have a meeting, but do not want to travel, then the only option is a telecon.  
2) Interview 
This is sure interesting approach and it should work well for smaller companies (as you have proven it in case of Assembla). Might not be so great for larger corporations, due to a variety of reasons (legal, political, etc).  
1) Estimate 
Disagree in majority of the cases. You need to estimate in order to get a buy in from stake holders, unless you fully own the company and the project. You would not hire a painter to paint your house or carpenter to lay floors unless he would give you an estimate, would you? So why would my CIO, CEO, CFO, or an investor agree to run a project if I don't give an estimate? 
* You already know what order you are going to do things in, and no estimate is going to change that.  
The only reason you know if because you did an estimate. You might have done it in your head, but you still have to do it.  
* You already know how much time and money you are willing to spend on the project.  
It only applies if you own the company. In many cases budgets have to prepared and presented for approval by big wigs who have a view of the big picture.  
* The estimate is going to be wrong anyway.  
Not true. With experience you can get the estimate pretty close. Also, this is what risk planning and reserves are for.  
As a general comment, I would like to praise you for your thoughts. I think they work well for a small company, and a company owner in particular. However, in most of the cases they will be a disaster in larger companies, multi-million dollar projects, etc. There is a time and place for every method, and I am happy that you found one that works the best for you and your company. After all , Assembla's success is my interest as its customer.

posted @ Thursday, April 23, 2009 4:23 PM by Eugene

Great article Andy!  
I have seen many projects in the past that have taken longer to get to a spec than the size of the work – especially in large corps. It seems like madness but it happens all the time.  
I am also warming to your idea about work trial over interviews. More and more it seems that interviews can be very random events and therefore making a hiring decision based on your perception of the interview is really just guess work – a lot like picking stocks on the stock market.  

posted @ Sunday, April 26, 2009 11:14 PM by Ryan Walker

For the last couple of years, as part of the interview process, if we feel the candidate is strong enough we invite them back for a programming session. We sit them down in front of a PC, fire up the IDE and ask them to show what they are capable of. It isn't a complex task, just a simple message of the day application - but we want the messages in a database and a proper architecture. We realise it is overkill for this type of application, but we ask them to show off and over-architect anyway just so we can see what they are capable off. 
The results have been astonishing. One guy sat for 4 hours and in that time wrote 2 lines of code (yet he interviewed really well). 
Of all the people we've hired based on this I've never had a dud. My rule now is: Interview for personality/team fit. Programming test for ability.

posted @ Thursday, April 30, 2009 3:58 PM by Colin Angus Mackay

Hrmm - you develop software for a web platform that customers subscribe to. What timelines do you have? I work for customers who purchase software or software services from us. This is a huge piece of the agile methodology that I don't see fitting in the provider-customer relationship. Customers need to budget as much as anyone does. You just can't tell them that 'no, we're not going to design this' and that 'we'll get it done when we get it done and just keep charging you along the way'. 
Find me a customer that will accept that, and I'll retire right now. 
The Agile approach sounds all peachy - but in the business world... hmm...

posted @ Friday, May 01, 2009 2:51 PM by MikeB

I see your point Andy - or, really, I -want- to see your point. I love the agile concept - however, again, I'm not sure that it works when a customer is purchasing a deliverable product from you. That is, when we're not building a product internally, or as a beta, to be released later for sale to a community (like Assembla and Google products).  
Let me try to explain my thinking (correct me where you see me wrong) - So in your case, you can certainly work the agile approach because you know that whatever changes you make to the solution are out of your own pockets. If its a worthwhile change, where you see the potential to increase price or number of sales, you'll choose to add it in. 
Contrasting this though with customers coming to you for a specific product to be built specifically for them - they need to know what it is going to cost; they'll require it - 15+ years in this business I've never seen different. Maybe I'm doing somehting wrong, I'm always one to listen to critique...  
So, how can we give a price tag and at least a close timeline if we start so loosely and allow change along the way. 1) we never know what it will cost us to build it and 2) the customer will never know what it will cost them to have it made. 
I know I'm probably in an old school paradigm, but I am able to look outside the box... I just wish I could make more sense of this - I'm even having a tough time explaining it here. But really, I do appreciate your feedback on this as I really do want to visualize this working the way its supposed to. I just haven't found a customer to support it - they have to know how much money they are going to spend - just like everyone else. 
Thanks for your reply.

posted @ Friday, May 01, 2009 3:21 PM by MikeB

Very good clarification Andy, thanks. This has spurred a great conversation. I have often wanted to hear how another business owner utilizes this agile approach. I'll take a little time to re-read and further absorb your response - I may reply or may not reply again - but your post allowed me to air something that has been bewildering me for some time. heh  
It was particularly useful hearing a response from a business owner and developer, rather than simply from a developer high strung on agile. 
Thank you.

posted @ Friday, May 01, 2009 3:50 PM by MikeB

Comments have been closed for this article.

Follow Assembla

twitter facebook youtube linkedin googleplus

Get Started

blog CTA button

Subscribe by Email

Your email: