Getting Real

Getting Real by 37signals is a nicely organized collection of statements enforced by references to their own software and quotes from influential people. The form makes it easy to follow, but also easy for me to share a few highlights.
I definitely recommend reading the book - it is not the Holy Bible of software development, but it definitely provides valuable food for thought.

First chapters of the book promote staying small - in terms of company/team size, budget, toolset and product feature set. Let your constraints be your advantage. Get a simple product done fast (and imperfectly), present it to your audience, don't delay release until you have all the features polished (and obsoleted) - I totally agree.

What is a bit controversial is the strong resistance to new features. Every feature has a cost that is easy to overlook when you are considering the idea, but you need to implement something to differentiate from your competition and provide enough functionality to justify using your product.
Your Ta-Da (web based todo list) is nice and simple and elegant and sufficient for most and whatnot, but I will not use it (or pay for it) until it integrates nicely with my cell phone, sorts by due date and has priorities.

The book presents a lot of ideas with justification strong enough to at least consider them. There are however a few highlights especially worth implementing:

• Build for yourself. If you do not really need and use your own software, it will be at most mediocre. If you are really lucky.
  
• Embrace constraints. Otherwise they become your disadvantage and you loose.
  
• Pick your audience. You cannot please everyone.
  
• Make design decisions. Don't introduce a config option for every small aspect of your application. Find out what would work best, because most customers will not have enough patience to do it by themselves.
  
• Be aware of your technical debts. It's fine and sometimes even desirable to hack together a solution that just works, but remember it comes with a price. Be aware what the price is and manage your debt consciously.
  
• Develop using real data, or the only thing your application will be able to process and display properly would be your Hello, world! equivalent. I cannot overstate the importance of this one.
  

Now go and read the book :-)

Auto adjust in JIRA's Log work done is a Bad Thing

To make myself clear: I refer to this piece of "Log work done" screen.


When "Auto adjust" is selected (default), the "time spent" is also subtracted from remaining estimate.

Why this is wrong?
Because "Time spent" and "Remaining estimate" are two distinct metrics that have little in common, except having the same unit. The correlation between time spent and estimates is something that should be measured, not assumed. They should not be adjusted by the same amount, at least not by default.

Lets assume that remaining estimate is 2 days, as in the picture above.
I log 2 hours of work done.
The remaining estimate would by default be adjusted to 1 day 6 hours (or other, depending on how many hours a day has in your setup).
Would I set such estimate if I was asked explicitly? Would I really say "after spending 2 hours today I estimate I need whole day tomorrow and 6 hours of the day after"? Rather not, at least not most of the time (default). I would say "I need about 2 more days", or maybe "I should be done in about 1.5 days".

The default should be "set estimated time remaining" -- to encourage the developer to think about what was left to be done. Otherwise the remaining estimate is just the original estimate minus total hours worked.
Without asking the developer to adjust it manually, the remaining estimate is just decreased until one of the following happens:

• the task is done and the remaining estimate is suddenly set to 0,
  
• the remaining estimate reaches 0 (or close) while the task is not done, then the estimate is adjusted - effectively we get the "90% done syndrome",
  
• miracle happens and the developer voluntarily takes the responsibility to actually set the remaining estimate every time the work is logged.
  

Leaving auto adjust as the default allows the developer just to avoid any estimation, with the excuse that "the computer did that for me".
Disabling this option, or at least making it non-default, would make the developer responsible for the decision:

• I made some measurable progress, no new obstacles found, set estimated time to ...
  
• No significant progress today, leave existing estimate
  
• I don't feel like thinking today, let the computer auto adjust (for the last time)