On Our Project, We're Always 90% Done

blog
41

If I may make one suggestion…

First, Jeff…I loved your article about the quantity vs. quality and I think it applies here.

I’m a developer, like most people here, and I build a lot of software. However, unlike probably most of the developers commenting on this blog I have a team of ten people that I employ and I’m the head developer PLUS I’m the guy at the end of the day going Criminee…I have $30,000 in payroll due tomorrow.

So the challenge for me has been how to do I get organized and sharpen my skills at the same time? I build software that keeps me organized!

I’ll tell you what; build a to do list or two that meets how YOU like to work and it’ll be worth it. As my skills and needs have changed, so has my to do list program. My program meets MY methods of organization and as those needs change so does the feature set.

Just a suggestion.

42

I surprised people gripe about the delays. Anyone who has ever worked in software should know that delays are practically a way of life.

List or no list, software is still a tricky beast!

(Yes, you can minimize them, but come on!!! they still happen!!)

Keep up the hard work Jeff. I’m excited to see the site whenever it’s ready.

43

I usually tell me team that if there’s a but followed by the word done then its not complete!
I usually hear things like its done but…

Shamelle

44

I think that the problem with all the project management is that you’ll be stuck at 0% for a long time trying to map out everything, which could have been spent doing a POC or base implementation and which in the end will give you a better idea of the actual requirements. Oh, i’m 100% done i already have the requirements and implementation plan, and then BAM you encounter the issues that only come up in development and have to replan again.

Not defending all action and no planning, just that alot of planning will kill a project.

BTW, i think this post of yours is actually in conflict with the previous one.

45

@Karellen

I don’t know if you noticed, but on the first article you linked to, it specifically says that it is outdated, and no longer valid, and specifically says not to read it.

46

this is also one of the cardinal rules of GTD, without a to-do list you can’t finish anything, software development is not an exception.

47

I found Software Estimation, demystifying the black art a good read for this topic. Although by definition boring to practitioners, Steve McConnell’s emphasis on empirical data points and the avoidance of guesstimation makes the content far more applicable than similar textbooks I’ve come across.

48

My lists tend to have a status entry for each actionable item (ie my actual assignments, rather than individual tasks that lead to the assignment being complete). In my current position, the status reads as follows:
DEV
Peer Review
TEST
User Acceptance Testing

and then if it passes all of those steps, I label it Production and move it to a different list, where I can pull back the details and notes I took on that particular item if something slips past testing. I also keep a list of every file I change while I’m working on that item, because I don’t want to forget to check some little change to one file into source control and then spend more time looking for it later when it won’t pass test or peer review.

49

Yes, I did notice.

But, I think that the first has a few interesting ideas that aren’t in the second. It seems more targetted towards individual developers - it tells you how you can manage your own time and come up with your own estimates more accurately than before, all with a really simple spreadsheet.

The second, evidence-based scheduling article seems to be more targetted towards project managers who oversee a number of developers, are far enough away from the estimates to do meta-analyses and such like, and have the time and incentives to create the interesting graphs and velocity measurements. I think a lot of individual developers would look at the second article and think that that’s a lot of work for them, more work than they can justify, if they just want to improve their own work.

So while Joel would like you to not read the first article, I still think it is worth reading, especially for individuals. If you’ve got a manager who’s willing to implement the ideas from the second article, great. If you don’t have such a manager but want to improve your own workflow anyway, then I’d say the first is more relevant.

50

Well I just gave the link to one of my PM’s and he said theres a problem. I’ve never read a book!!!

Why does it not suprise me!!! Does it come in audible version!?!?

51

From what I have seen the reward cycle in IT has a number of problems:

  1. The manager normally has no concept how subordinates do what they do, so are normally incapable of realistically measuring success. This is NORMAL in IT, because the manager is busy managing, not becoming a technical expert. So judgements on rewards almost always come down to perceptions and perceptions are almost never accurate.
  2. Teams are more concerned about lack of performance by other members than they are about individually being singled out for praise.

In both situations a 360 degree process, where customers/clients/users, managers and team members all get to rate others. This way a manager may “love” a sycophant, but team members are able to report contribution and actual skill. Similarly, this gives the subordinates a chance to rate their leader. It is all done anonymously to avoid reprisal. In my experience this is the most accurate measure as it removes one person’s perceptions as the basis of assessment.

On the point of money, a couple of bonuses/raises in a row can become expected, so that a cycle of no raise can actually be seen as punishment.

52

Way to man-up and own the responsibility, Jeff! This was not only a good post in it’s own right, but it was very humble and honest of you to respond to being called to task on your scheduling. Thanks for putting yourself out there.

Part of the problem I’ve had with making lists of what I need to do is the hubris of either I know what needs to be done, I don’t need a list and the aforementioned by the time I make the list I could be DONE with it! But, honestly, there are some things I probably don’t want to know that I have to do and writing them down in a list is not only acknowledging them, but is a form of committing to them :slight_smile:

However, going from development to management to development again, I find myself WANTING a list of prioritized tasks. Partially because I want to know that what I’m working on is important (even the small stuff) and that my leadership (manager, VP, CEO, etc.) have all THOUGHT about what needs to be done, given a value to it and consciously decided what is more important than what.

That frees me up to not be worried about the stability of my job environment and to just code like a mad dog (…who’s focused and directed and deliberately working on important things. Bad analogy, I know).

Anyway, excellent and thanks!

53

I really like The Art of Project Management by Scott Berkun (http://www.amazon.com/Project-Management-Theory-Practice-OReilly/dp/0596007868).

54

A slaves work is never done – Jam tomorrow, never today.

55

My rule is to make the most sober and pessimistic estimate you can and multiply it by two. Jeff, I’m sure you thought your initial estimate was realistic. If you had used the x2 rule you would have been dead on.

I did this once for a client I was working for. When I told him the estimate he said it was way too long and cut the estimate in half to what he felt was more realistic. Guess how long it took? :slight_smile: Even when I’m right, I’m wrong.

I always work from lists when I’m trying to finish up a project. Once I feel like I’ve done all the major stuff I start listing all those annoying little fit and finish jobs in order to wrap it all up. The funny thing is that if I start with a list of 100 items by the time I’ve got 50 done I’ve accumulated 50 more. So even that estimate is crap. Yes boss, I did half the work, but I’m only 33% done. That’s about when I start triage - next release for you and you, etc.

At least if it’s on the punchlist it gets done (eventually).

56

Jeff, I was surprised to learn you were 37 (from the stack overflow site) – many of the articles you write and things you say (here and the podcast) make you come across as a much (much!) younger, inexperienced developer. For example, I’m almost pathologically bad about writing things down. How’d you get this far in the development world without being called out on that by your bosses?

57

Scott Hanselman had a great podcast with one of the creators of Scrum on what is the definition of done for software.

http://www.hanselminutes.com/default.aspx?showID=137

58

Would somebody tell me how to estimate the time needed to debug?

59

@dwj Obviously the wisdom that comes with age that you refer to doesn’t include tact.

60

I have been once taught (by my former programming teacher; he worked for big software companies in Germany and Japan) the most essential truth about software development ever:

You cannot estimate how long a programming task will take; period!

I know that there are Mio of people who disagree, but I think this is absolutely true. Let me add some more quote

Programming is not like building a house over and over again. If you build your first house, you have no idea how long it will take to build a wall, make the roof or creating one square meter of floor. Once you did all this, you know how long it took and when you build your second house, you know that it will take about as long as it did the first time, if not faster, since you are getting better at a task the more often you are doing it.
Every piece of code you write is a new piece of code, you are never repeating the same task again. Why would you repeat the same task? If you ever need the same code again, you copypaste it; that will take you about 5 seconds. If you ever need the same application again, you just copy the one you wrote last time.
A software developer faces the problem that he needs to write new code every day, as there is no point in writing old code again. So every time the task is a new task for you. It’s like you are building a house today, a car tomorrow, and creating a lovely garden the day after tomorrow; and you are always doing it for the first time. How can you estimate in advance how long you will need for it?

This so very true! After years of development I can assure you, I’m doing something new every day. I’ll continue to quote:

Thinking you can estimate a task you have never done is just an illusion. You can make a vague guess, sometimes it’s good, sometimes it’s horrible. Sometimes you need twice the time and sometimes only half the time you estimated.

Actually all my time estimations are, well, I just make up these numbers. I have no basis for them. I could role a dice and the numbers would be as accurate as they are today. Quoting again:

Programming is like art. Ask an artist how long his next painting will take. Do you guess you can get a reliably estimation? His picture is done, when he considers it done. He can’t say in advance how long it will take. He might be 99% done and then consider some things need to be repainted and within a couple of minutes the state falls back from 99% to below 80%.
There will be the day where software developing companies are going to realize that. That’s why OpenSource software is often better in aspects like performance or security; it’s not time based. It’s done when it’s done. The developers themselves decide when it is called 1.0, not some marketing department or some supervisor. If they consider something a nasty hack, they’ll fix it, even if this means it takes another 3 weeks for the software to be done.

As odd as this might sound, but I personally would prefer if the time frame is set from above. I can surely make a list of all tasks to be done and show them to my supervisor every day; but I can’t say how long each of these tasks will take.

It’s a different situation if my supervisor says Okay, for that, you have one day; for this one, it’s very important, you may take up to three days; and for this tiny one, investing more than half a day won’t pay off. If I know that I have only one day for this task and I start in the morning, I know it needs to be done before I call it a day. That means at the end of the day it’s done. Whether it’s good or not, whether I would consider it done or not, doesn’t matter. It’s done, because the time frame says it has to be done and if it’s far from perfect, far from good, far from reliable… it’s not my problem. The time frame dictates me when it has to be done.

If my supervisor then looks at the result and says I’m not happy with it. This is too unstable, too slow, looks too much like a hack, I will reply Well, you only gave me one day, that’s the best I can come up with in one day. Give me more time and I will make it better. Then it’s up to him to give me another day or maybe two days, to make it really good; or maybe not and it will stay as it is right now.