Thursday, September 22, 2005
Inflated requirements
The concept of small increments iterations in a project allows a project team build the system incrementally in small chunks. This in turn allows user to see the system and be able to react to it or give feedback much faster than traditional waterfall method.
There's a "process smell" in iterative world today, where a requirement/user story starts out small but keep increasing in the number of success scenario thus affecting the original estimate of story. This sort of activities seems harmless at first, since they changed a little at a time, but could potentially grow infiinitely.
And it left poor developers scrambling and changing their work b//c of this constant changes, thus leaving it up to the project manager or the technical lead on the team to voice the concerns and stop the activity to become the norm.
There's nothing worse for developers morale than to see his/her story is never completed due to constant additional changes to their work.
This activity also relates to piling on multiple defects into one defect filing which will have the same consequences for the development team
There's a "process smell" in iterative world today, where a requirement/user story starts out small but keep increasing in the number of success scenario thus affecting the original estimate of story. This sort of activities seems harmless at first, since they changed a little at a time, but could potentially grow infiinitely.
And it left poor developers scrambling and changing their work b//c of this constant changes, thus leaving it up to the project manager or the technical lead on the team to voice the concerns and stop the activity to become the norm.
There's nothing worse for developers morale than to see his/her story is never completed due to constant additional changes to their work.
This activity also relates to piling on multiple defects into one defect filing which will have the same consequences for the development team
Thursday, September 15, 2005
Hibernate Session is not the same as Unit Of Work
A Unit of work usually defined operation(s) that will be executed within a single transaction to preserve
the ACID rule. Hibernate session however could be tie in with a request (ie. web request) since there's no
guarantee to preserver a session to be executed within a single transaction.
Martin Fowler's definition of UnitOfWork is exactly that
http://www.martinfowler.com/eaaCatalog/unitOfWork.html
"A Unit of Work keeps track of everything you do during a business transaction that can affect the database. "
the ACID rule. Hibernate session however could be tie in with a request (ie. web request) since there's no
guarantee to preserver a session to be executed within a single transaction.
Martin Fowler's definition of UnitOfWork is exactly that
http://www.martinfowler.com/eaaCatalog/unitOfWork.html
"A Unit of Work keeps track of everything you do during a business transaction that can affect the database. "
