Archive for the ‘project’ Category
March 22nd, 2009
>
I heard a thing the other day I haven’t heard for a long time. “That is not my code”
I believe no code and all code in your current project is Yours. There is nothing like finding a bug and leaving it be. If you can’t correct it, flag it. Either in a bug tracking system, to the person currently working with that part or to wherever your project stores possible riscs.
This my code-your code mentality mentioned above lead to the bug being forgotten.
That is not considered good.
March 20th, 2009
>
A small rule I have while estimating time or looking into a system is to run CRUDSLM against all business objects and possibly all database tables.
I make sure that every business object has one tick in each C, R, U and D. This is the normal case and by doing this I guard myself against forgetting something. There are times when things aren’t updated and even not deleted but then I know this and can argue for it.
It is a fast exercise and I usually run it only once against every business object and once against every database table.
For time estimation I extend the CRUD with SLM where the letters are Search, List and Manipulate respectively. Many times, especially with the main business objects, they are Listed and Searched. Then for reports, imports and exports they have to be Manipulated too.
I have many times found out that Delete is missing.
January 5th, 2009
>
People tend to do two things. What they think is fun and what they are measured on.
Measuring is a two-edged sword and should be used with prejudice.
Giving people fun things to work with is more like icecream with a strawberry on top.
Like this:
People do things they are measured on. Since one cannot measure brilliancy and why-you-rise-in-the-morning, measuring tends to give focus to other things like klocs or amount of green unit test lights.
I worked with a guy who was fast as lightning with the drawback that everything was finished the first day; often even before the code was written. So instead of harrassing him about estimates and CRUD I let him hack away and just finished what he started. His focus was code code code and my became customer satisfaction. Both of us where satisfied.
December 30th, 2008
>
An important code regarding programming is to write code that is easy to read.
I have many times written code, polished it and then rewritten it to the original text since it was easier to read. This is considered mature and a good thing.
A month ago I wrote code like this:
return AllControlsRecursively((Control)form
).FindAll( control => (null == control as IDirty) ? false : true
).ConvertAll( control => (IDirty)control );
I thought about it for several days and then decided to leave the code as it was.
My reasoning behind this is that once upon a time I had problem understanding Fn in BASIC. Later * and & in C. Then I had to learn inheritance, virtual methods and abstract. Today it is lambda methods, WCF and WPF.
One day one has to decide to get the fingers dirty. That day is every day.
December 29th, 2008
>
The Drop down list box is often, incorrectly, called a Combo box.
It does not sound like a big issue but user interface wise it is. A Drop down listbox only takes existing values as a Combo box allows entering of new, unknown, values. When talking about Combo boxes don’t forget to clarify what should happen if the user enters a value that doesn’t exist in the list.
Like this:
“We would like to select the Customer from a Combo box.”
“What should happen if the user enters the name of a Customer that doesn’t exist?”
“The Customer should be created.”
“Where from?”
May 3rd, 2008
>There are no bugs and issues. There are no features and bugs. There are no priority changes and work items. There are no new use cases and lack of backup and ugly login page and bad performance.
There is only change.
Do not sigh when the customer comes with a new all important requirement. Put it in the list of changes.
It is only a change.
March 7th, 2008
>Prioritization is about removing things from a list – not putting them in.
The above is very easy to approve of until one is faced with the actual task of removing something.
I have a trick that seems simple enough to work. I have used it with a customer and gotten to know things he didn’t know himself. I use it on myself and get wiser every time.
Take this list with “all things” and separate it to three piles of equal size. Prio 1, 2 and 3. If three piles is too hard, try 9; but do keep them of equal in size.
This is hard to do and the result is not the final prioritization but it gets blood to the brain and forces the synapses to fire in new patterns. To remove things.
I do not tell the customer but know myself that the lowest third in the list will never be done due to money, time or -best of all- the very requirement disappears.
December 30th, 2007
>This message will be repeated in english.
Om det tar 8 månader att bygga ett system så tar det 8 månader att bygga systemet, hur aggresivt man än lägger tidplanen.
If it takes 8 months to build a system then it will take 8 months to build the system, however aggressive we try to plan.
December 16th, 2007
>This message will be repeated in english.
Hur länge skall man speca, planera, undersöka?
Ett enkelt svar är: “Tills man inte råkar ut för överraskningar.”
Eller: “Tills de positiva överraskningarna är lika många som de negativa.”
Eller: “Av de oväntade sakerna som dyker upp finns ingen jag kan förutspå.”
How long should one plan, do specification or experiment?
One simple answer is: “Until you don’t get any more surprises.”
Another is: “Until the positive suprises are as many as the negative.”
Or: “Among all surprises that will surface there is none I can predict.”
December 12th, 2007
>This message will be repeated in english.
Vi verkar inte separera roller på samma sätt i Sverige som i USA.
Jag anser programmering hänga tätt ihop med design som hänger tätt ihop med arkitektur.
Samma människa gör ofta alla saker, bara med olika hattar på. Ibland har man samma hatt i hela projektet och ibland byter man varje minut.
Se på Microsofts licenser där VSNet för arkitekter inte innehåller funktionalitet för att testa. Och utvecklaren har inga kraftfulla databasverktyg.
Lösningen är att köpa deras alltihopa-licens men den är gördyr.
Bortser vi från pengarna kan det ändå vara ett problem. Om Microsoft tror att olika människor är fasta i sina olika roller smittar det av sig på produkterna. Och då kommer det vara svårare att hantera projekt på “vårt” sätt med deras produkter.
It seems like we do not separate roles the same way in Sweden and USA.
I say programming is tightly connected with design is tightly connected with architecture.
The same person often does all things, just wearing different hats. Sometimes the hat is worn throughout the whole project and sometimes changed every minute.
Look att Microsoft’s licenses for VSNet where architects do not have testing functionality. And the developers do not have any powerful database tools. The solution is to buy their all-in-one-box licens but it is Expensive.
Money aside it can still be a problem. If Microsoft believes different people are stuck in different roles it will colour the products too. And then it will be more difficult to use Microsofts products to handle projects “our” way.