Category Archives: Uncategorized

Testing WordPress

Call me confused… when I “View Site” from word press, I see the original movabletype blog.

In wordpress I see blog posts from may, june, july, october, october 2009.

I also see comments from WP posts. But now I cannot see those posts at all.

In movable type I see no posts between Feb 2009 and Feb 2010.


Something screwed up with web config on server?

Truth Hurts

Check this out…

A Better Team

and take the quiz!

My current team and I need to work to improve ourselves :-

But that was just my assessment… I’ll try to get the whole team to collaborate on the “team” answers and see how that compares.


An agile modeling poster:

How does agile prevent stovepipe systems and implementations. My inquisitor seems to think that agile development processes actually increase the incidence of stovepipe systems and thinking. (I’m paraphrasing here)

Agile is recursive.

Just as the power of components, objects, interfaces is applicable in the small or in the large…

The parallel being: the mere existence of the “tools” to avoid poor solutions doesn’t mean that poor solutions will not happen. We still have excellent code and poorly-written code.

The overarching agile requirement is to use good old-fashioned, smart thinking.

Agile neither precludes nor promises brilliant designs and abject failures. Only people can do that.

Apply the tenets of agile development recursively “upward” and you might be able to avoid stovepipe thinking.


Building an application is a lot like gardening, or better, farming.

Are you doing a quick app (maybe a flower pot), or a mission-critical app — where you need sustainable farming techniques?


Scott Ambler shared this link

agile schmagile…

The first slug of slides (which i have not gotten past yet) pointing out realities of some development efforts being lousy has nothing to do with agile and everything to do with people doing a lousy job at software development. News flash: anyone can screw up doing a project or misinterpret principles of development. Is that somehow the fault of the Agile Manifesto? I propose to consider it be the responsibility of the people involved…

If I get the stamina to respond I will, but here is just one stupid example:


second first iteration

we had our second iteration kickoff today.

the first iteration was a bit premature — but i knew that. there were still issues with the team’s preparation:

  • getting their systems setup
  • understanding the best project structure
  • reconfiguring SVN
  • figuring out some of the flex UI issues
  • determining how to do CFUnit properly
  • etc.

The team was also new to

  • working collaboratively across multiple time zones,
  • doing an agile project,
  • doing a feature-driven approach,
  • having to estimate features,
  • doing domain modeling
  • considering a technical architecture
  • using tools like the confluence wiki, jira issue tracking, and IRC

Nonetheless, nothing like a deadline and an exercise to help bring things to the foreground!

We allotted only 25% of their available time to be allocated as ideal engineering hours for the task estimates. About half of the iteration or more was taken up by issues with infrastructure, set up, etc. Surprise, surprise, we got 17 of 31 issues completed. about 50% — which stands to reason.

there are a couple of lingering technical issues as we start this iteration. we rolled over the unfinished issues for iteration 1, added a new round of follow-on issues, and went through an estimating and assigning session.

progress is being made on many fronts. now to see some features roll off the assembly line in a bit more predictable fashion for this milestone!

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.)?