Monthly Archives: April 2007

sum of the parts

working with a new development team on a business app to be surfaced through a portal. taking them through an agile project approach. spent the past few weeks doing:

  • domain modeling
  • feature list elicitation
  • looking at the technical architecture (the “how”)
  • UI sketches

We then did a first pass at estimating the features… An estimate of how long it would take to build the feature — including everything from persistence to surfacing it on the UI and all parts in between.

“But do we need to estimate building the UIs too?”

That’s a good question. I explained that there were lots of features that contribute to a given UI screen… Therefore, there were lots of “pieces” of estimates from each of those features to be built. These piece-wise estimates of the UI will ultimately contribute to enough hours for the overall UI screen. I think of it as a bottom-up approach to getting a reasonable estimate going.

You can also look at a UI design and estimate it top-down. Check the two against each other if you like…

Not to say that we won’t also have some specific UI work. Just that we do not need to count the full cost of building the feature *and* the full cost of building the UI.

How do you estimate?

lines of code

i was consulting at a client a couple months back. the president of the company was concerned that his staff was not as productive as it used to be.

about a year or two prior, the owner and the president decided they wanted more software to be produced. they decided to add offices overseas and double (at least) the staff.

shockingly… two years later, they are 3 years behind on delivering a new version of their flagship product. on top of that, there is little known about just what they have in the way of valuable assets in the project source code.

now the president is looking to measure lines of code and to see what the difference is between team “A” versus team “B” to try and maximize developer productivity.

i tried to make a few forays into explaining there is more to development productivity than LOC. but i didn’t have much luck. maybe i’ll check back in a year and see how they are faring.

any silliness like that where you work? or, better, any successful ways folks are measuring developer output (#feature points increasing over time, etc.)?

security policy or what?

Here is a post about a software company (that does not need this level of security — they are not doing secret govt work or sensitive corporate work) that has been informed about some new security measures coming along:

  • No cellphones
  • No Internet
  • No USB storage device of any kind (this includes iPods)

This ought to make the software developers happy!

Why bother letting them use the power of the Internet and Google to get their work done better?

Maybe there are some cases where such measures are needed. However, I tend to trust first, rather than act accusingly first. If the company has such little regard for the ethics of their employees, they should fire them all and hire new ones.

Maybe what should be done is have a place where evil employees can go to:

  • Smoke
  • Use cell phones
  • Look up stuff using the web
  • Looking for the fastest way out of that job

If you work in a place like this, you should seriously consider appealing to management to have a sense of sanity and rescind such stupid mandates.

Or better yet… mandate that everyone have encrypted emails and all files must be encrypted. You refuse to email anyone without full encryption. Set up a key server and have everyone create a key, then have a key signing party. So even the smallest and most trivial of communications must be secured with big-time security! If you work with business people or other developers around the world, treat everything as if it is national security — like spies.

Or, just get a job at a better place where you get treated with respect!

Money isn’t everything 😉