How to Effort Estimate? Manage Java/JEE based Project? for first time Lead/Manager

[Akram Chotu]

I am an experienced Java/J2EE developer who worked on Enterprise Web Applications, SOA, Web Services etc. I have not lead any big teams earlier. Just lead small projects with 1-2 developers.

Now I got an opportunity to work on a new assignment where I have to lead 4-5 junior developers. All this kind of calls for some Lead and Manager(not a pure manager per se though) skills for firt-time Managers/Leads like me.

Here are my new assignment details:
a. My current assignment is a new assignment where I need to work on 7 years old Web Application based on technology like Java, JEE, Struts, JSP, Asynchronous messaging, event based messaging etc.
b. I have to lead a team of 4-5 developers
c. we need to work on bug fixes or work on change requests that can be major enhancements to the web application or bug fixes

Now my question is, when a change request comes, how do I estimate the effort for myself and my team members for which I am the lead ?
how do I schedule my project ?

how do I manage my team members day-to-day tasks, estimate their task efforts? estimate the change requests? how do I manage my project ?

are there any good books that can answer my questions for first time lead-developer or manager(not a pure manager per se though) like me ?

[Akram Chotu]

any JavaRanchers willing to contribute to this post ?

[Tim Holloway]

Determine what the major tasks are. Break them down to sub-tasks. Estimate how long it "should" take to do them all. Double that. Better yet, triple it. Threaten anyone who says "All You Have To Do Is..." with assault. That goes for both users and developers, except that it equally applies to developers who say "I" instead of "you".

You'll probably still come in late, but at least the overruns won't be quite so severe. The downside is that management won't want to hear the more accurate estimates and will quite likely sit on you until you give them a "more realistic" estimate. Meaning the one they want to hear, as opposed to how long it's really going to be.

[Akram Chotu]

Thank you Tim

That goes for both users and developers, except that it equally applies to developers who say "I" instead of "you"

Can you please explain this point ?


Also, as requested in my original post, are there any good books/urls that can answer my questions for first time lead-developer or manager(not a pure manager per se though) like me ?

[Tim Holloway]

AYTHDI is, In My Humble Opinion, the deadliest phrase in Information Technology. It's used all too freely, and it's dead wrong. What seems simple to people is not simple to computers. And to get computers to do anything means that they have to be instructed in meticulous detail. All of which consumes a finite amount of time, and that time adds up. And up. And up. My own experience has been that the "tricky" parts of a project - meaning those that require specialized technologies and new approaches - often are only minor consumers of time, even though, as unsolved problems they loom large in our thinking. Instead, the major time-burners are those that involved getting that last pixel slid over on the CSS and having 3 people spend 2 days solving a problem that then turned out to be obvious. Or worse, wasn't actually a problem to begin with.

People have always been optimistic when estimating time and resources, and that's why the adage that "Everything takes longer and costs more" is much, much older than computers. And why, even with the greatest engineering resources, public works projects continue to come in late and over-budget. This optimism occurs on both the producer and consumer sides of the fence, which is why when a developer says "that's easy. All I have to do is", you should immediately be sceptical.

In my misspent youth, I collected a considerable array of books by people such as Ed Yourdon, who have made it their profession to analyse the software development process. A number of observations have been made over the years, some controversial, and some actually overturned, but the one thing you won't find is a hard-and-fast set of estimating numbers. That's because nobody has come up with a one-size-fits-all set. In fact, Yourdon's comment was that when people are productive, they're very productive, but when they're not, the other extreme applies.

One reason I have for the "doubling" rule comes from hard numbers, although it's typical of what I've seen throughout my career. I worked with a group that was meticulously metered on a major project. One of the things that the reports revealed was that almost every person on the team had a fairly accurate idea of how many lines of code they could produce in a given time period. However, their estimate of the number of lines of code required to accomplish a task was only half of reality.

So that's some good news and some bad news. There are no cookbook numbers. But experienced programmers do have a fairly accurate idea of what they can do and how fast they can do it, and therefore you can rely on the estimates that you and your team members make. Just don't rely on anyone's estimate of how much actually needs to be done.

[Joe San]

Akram Chotu wrote:I am an experienced Java/J2EE developer who worked on Enterprise Web Applications, SOA, Web Services etc. I have not lead any big teams earlier. Just lead small projects with 1-2 developers.

Now I got an opportunity to work on a new assignment where I have to lead 4-5 junior developers. All this kind of calls for some Lead and Manager(not a pure manager per se though) skills for firt-time Managers/Leads like me.

Here are my new assignment details:
a. My current assignment is a new assignment where I need to work on 7 years old Web Application based on technology like Java, JEE, Struts, JSP, Asynchronous messaging, event based messaging etc.
b. I have to lead a team of 4-5 developers
c. we need to work on bug fixes or work on change requests that can be major enhancements to the web application or bug fixes

Now my question is, when a change request comes, how do I estimate the effort for myself and my team members for which I am the lead ?
how do I schedule my project ?

how do I manage my team members day-to-day tasks, estimate their task efforts? estimate the change requests? how do I manage my project ?

are there any good books that can answer my questions for first time lead-developer or manager(not a pure manager per se though) like me ?

It sounds nothing like a new development wherein you will technically architect the entire system and explain that to your team mates and do the actual development. In your case, you should be the person that understands the system completely and match that with the business functionality so that you can easily understand how much time it would take for any change request. Once you know how much time, you will know how many resources that you need to finish it.

[Akram Chotu]

Thank you Tim and Jothi.

[Tim Holloway]

Hmmm. It looks like my last reply got lost.

I'm afraid that I'll have to take exception to the idea that maintenance is different. First, because more typically, they discharged all the original developers a cycle or 2 back and even the current manager usually only has a rough idea of what's really going on. Secondly, because the AYHTDI syndrome applies just as much to maintenance as to original development, and I can even make a good case that even more concrete efforts like hardware upgrades suffer from it.