Light Use of XPlanner

I use XPlanner to track development process. However, in many cases e.g: very small team, small scale software, I don't use many of it's feature and use it as a very light project management tools that feels more like an extended todo list (which is good since it is simpler and does not get in the way of the development more).

Here's how I used XPlanner lightly :

• I filled mainly only text and description for stories and tasks, other fields are left in default
• No timesheet entry, just click "complete" when task is complete and change the stories to status to "implemented" when all it's task is done
• I monitor only what task is done and what stories is implemented

So, when it is used like this it's basically just an"over-featured" todo list, but it still has some advantage over generic todo list and that is the built in iteration concept. I can still feel that I am within development iteration. Also, when in other iteration I decided to use more of it e.g: timesheet, it is still there, ready to be used.

Programmer Maturity and Estimation Skill

How do you measure a programmer maturity?. Recently, I am beginning to think that it is reflected on how they estimate the project and task that they need to do.

Programmer that only work on small number of code and problem tend to highly overestimate or underestimate the complexity of a project/task. So, mature programmer is not (just) someone who could code, and estimate, very good and precise in well-known problem using language that he knows well. A mature programmer would also :

• know quite clearly what he need to do/learn/research on matters that he is not used to
  
• how much/how certain/uncertain the time to take to tackle it, substask and trouble that potentially come up
  
• make clearly-thought estimation, and most importantly
  
• not emotionally attached to a problem which means not knowing or estimate something as long/hard/unknown/impossible is nothing to be embarassed/defensive about instead it's for the best if everyone being clear on what can and cannot be done
  

Less mature one would tend to be more "aggresive" and eager to prove himself by estimating too optimistically or underestimating a complexity of certain task (by fear of losing credibility or eagerness to be accepted/approved).

I think it's the same as maturity in life, you are less needing of approval/praise or trying to satisfy/impress anybody too much and more focus on doing what you can do best and keeping your integrity checked.

It does not mean we need to avoid the unknown and avoid adventure, but being mature means being clear of it and not promising something beyond our integrity to accomplish it. Say something is risky when it is and let the stakeholder decide (and share consequences later), say something certain when you have a reference/experience of it and ready to take consequence if you are proven to be wrong (you learn something new anyway).

Unit Test as a Documentation : The Case of PureMVC

I stumble upon PureMVC while searching for lightweight MVC framework for C#. The learning experience of it is not what I call pleasant one. The official documentation (which still based on ActionScript version) use very long narratives with very specific term used throughout the documentation assuming too much that the reader already familiar with it. To make matter worse, there's no executable code to try anywhere. There's no one to blame, of course, since the site already say :

Beta - Unit tests are compiled and running in target platforms, as well as a Silverlight Demo. There isn't much documentation yet, however.

However, things are changing once I take a peek at the existing unit test. This is exactly the experience that Unit-Testing proponent refer to when they say "Unit Test as an Executable Documentation". It is truly function as a documentation for me, even better than pages-after-pages narratives. It's like a "picture worth a thousand words" experience.

By relying on the unit test I can make things work in very short time. It also make the pdfs that I've read earlier starting to makes sense (despite I still think the narratives need much work to be humanely-readable). It explain how I should use certain class and how it interact with other class and most importantly, how it can produce the expected result. I don't even to compile and run them to know that it will works, it seems quite clear that it will work (in fact, I don't even bother compile the unit test, a little work of copy and pasting already show in short time that it work in my own code).

I rarely on the other side of Unit Testing world i.e: read them to makes sense of the code. I usually read my own or the co-woker (which the codebase I share and already familiarity with). Seeing their usefuleness from the purely-reader side (since it's truly "someone-else's" code) gives me deeper perspective on how they can make a difference in understanding and using the completely new code.

Using Jude : Seperate Model and View

More...(drag mouse)

Open Link

Close Other Tabs

Forward

Duplicate Window

Close Tab

Copy Link

Save Link As...

Jude is a UML tools that I find very flexible since let the user do the way he likes it to without forcing certain structure. The user could determine what certain structure of the components and diagrams are meant to himself.

Here's one way of using it that is quite useful to me : make a separate model and diagram folder. I put all the UML components e.g: Class, under model and make all diagrams under diagram folder. With this I could reuse the same classes definition on several different diagrams. Any change to the class will be reflected automatically to others.

It's a bit more work since you have to do things in several steps :

• add any model under folder model e.g: right click on the folder -> Create Model -> Add Class
• Open the diagram and drag the Class there from structure view
  

With standard way of drawing, I could just click on the toolbar and I got the model I want in that diagram instantly. It's quick but it makes the model less reusable/centralized.

It's not always seems practical to do so though, for quick "drawing" I just use the toolbar and let everything e.g: classes and diagrams on the same folder. However, for relatively serious UML Diagramming separating models and diagrams is more convenient.

Combining Trac and XPlanner

I wrote sometime ago about how using issue/bug tracker (Trac) and progress tracker (XPlanner) is really helpful, at least in my case. It will be really good if those two really integrated, but unfortunately it's not the case right now. We need to "integrate" them manually.

Here's the main conceptual merging I have made between them to support the concepts I am using :

Tickets is Story, Story is Ticket

From here on it's like directing the flow of detail that is stuck in Ticket in Trac, connect it and let it trickle down in to more detail through Story "hole" in XPlanner. Every Story is a Ticket being done.

We could have best of both worlds with this connection. On the trac side we have more strategic view of the Ticket/Story (Milestone, Roadmap, Wikis) and on the XPlanner side we have Progrress/Development detail regarding it (Burndown chart, tasks drilldown, assignments, timesheet).

Some useful mechanism regarding this :

• Make a wiki shortcut in XPlanner to Trac so in xplanner you could type something like 'wiki:ticket/555' or 'wiki:changeset/555' XPlanner and it's wiki system will link it to the Trac's entry. We could do interesting with this like make notes in Task entry that link to certain subversion revision.
  
• Use 1 to n mapping from Trac's Milsestone to XPlanner's iteration. Pick story to be done in certain iteration from it's parent Milestone.
  
• Let all the detail concerning the Ticket (notes, references, updates, troubles) updated in Trac to avoid duplication or confusion. Position XPlanner more for scheduling, timesheet and log-like notes.
  

Trac and XPlanner has a very potential synergy which I think is worth exploring. It seems, by design, both are made to be complemented by the other or something else similar in nature.

Agile and Effectivity : Two Game at a Time

On the book "Agile Software Development", Alistair Cockburn wrote that there are two game running in parallel when people develop software. The two game can be summarized as :

1. Make code that work
2. Keep the code workable

If you ignore the item no.2 you'll get trouble sooner or later with the no.1. You could get away by ignoring item 2 in short time, but in the long run you will pay the much higher price .

I see the two item above parallel with, if not an instance of, the concept of Production/ProductionCapacity (P/PC) balance in Stephen Covey's book "Seven Habit of Highly Effective People". And if you look around for more, many problem following the same model : using tool vs. learning the new ones, adding more hours in one language with experimenting with the new ones.

Defining Effectivity as balancing between P/PC is like defining EffectiveCoding as balancing between Coding/Refactoring.

Essential Software Project Tools

Here is the summary of tools that I find essential for doing software project :

• Version Control System : Subversion
• Roadmap, Issue/Bug Tracker : Trac
  
• Iteration, Schedule, Progress Tracking : XPlanner
  

Why bother with any of those?.Any production-level software project would require the team to work on development incrementally and have feedbacks on how they progress towards the direction they would like to go.

Experimental and small program would have only several issues to develop, a small time window to manage ( "let's just get this work and see what happen, we'll think about what to do with it later" ), a little constraint to fulfill and balance. Our brain could handle that amount, maybe with a help of a text file/spreadsheet or two. However, production-level software would explode your brain if you try to manage it all in your head (or at least only left so small amount of space that is unusable for effectively coding anything).

Those tools helps the teams to

• Focus on the now (Progress Tracker) without loosing touch of the past (Version Control System) or worry about tomorrow (Roadmap, Issue/BugTracker).
  
• Focus on the work at hand without loosing touch of the big picture.
  
• Separate committed issues with the pool of incoming one without which there will be no milestone/releases/versioning ("let's start from scratch straight to version 5.0!") which a sure recipe for starting a soon-to-be-abandoned project.

In short, it let us to actually do the coding.

Having past beyond code samples and toy-problem, and when it times to get something worth-talking built, it's time to roll-up some tools to help us achieve it, version by version.

The Why Behind Agile Movement

I read "Agile Software Development Ecosystem" book not long ago. There's a good answer on a question : why it (somehow) works?. The reason lies behind the nature of software development.

Developing software is creative process. Despite there are a lot of tools, languages, components exist today does not make it a deterministic process and it will probably won't be in the near future. There's no step-by-step way to make a software that is guaranteed to produce working program. Every project seems to always pose significant amount of uncertainty.

I find it interesting the book called this kind of activity as Exploratory, creating ways and new mechanism, as opposed to Optimizing problem which deals mostly to enhance existing mechanism. Exploration problem is the problem where unpredictability is common and changes is nothing special and are welcome to happen any time. The strategy then is to spend effort to be change-accomodative instead of wasting it on trying to avoid the unavoidable change. Using optimizing activity to exploration problem is not a best fit.

Agile methodologies proposes things that makes development team could response to change more effectively. It seems the most suited way to deal with software development for now, at least until software development can become something more or less mechanistic, which is less likely to happen anytime soon.