truefalse

Personally I write xml comments on all my methods even though I am a fan of method names  enough describing that comments really are unnecessary.  By descriptive method names I mean that others also understand them.

In a project I stumbled upon this method:

private void ShowHideControl( bool truefalse ){...

Since I had the source code it didn't take much effort to find out what it did.

But a question remains - how do I present the problem for the original programmer without being rude?

Avoid code ownership

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.

Time estimation and business objects, CRUDSLM

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.

People do two things

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.

Code that is easy to read

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.

Combo box vs. Drop down list box

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?"

Unit testing - can be too much

I like unit tests, I really do. But I have also come to realize that many tests don't have to be done.

One can for instance code according to Fail At Once to make the compiler do the tests.
Or one can autogenerate code and hence only have to unit test a fraction of the resulting code.
Or one can du integration tests and take for granted that if the integration works the unit tests work too.

I have tried all three and believe in laziness - to get more done while working less. So I say that a thought out mix of all three above supposedly is the right way.

Patrik Löwendahl thinks approximately the same.

Everything is a change

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.

Prioritization is about Removing

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.

Postpone decisions

Delay the decisions until they solve themselves or disappear. Sometimes postponing is futile and a decision has to be made. Then make it, but not before.

Sometimes one need more balls to not decide than to decide.

( And or course... not making a decision is also a decision... )

Everything is a bug

This message will be repeated in english.

Allting är en bug. Eller snarare: allting är ett ärende.
Oavsett om ärendet skapar en krasch, är fel storlek på loggan eller innebär installation av en UPS är det något som skall tilldelas människa och tid.

Min åsikt är att lägga allting i samma hög. Och med allting menar jag allting. Sedan prioriterar man ärendena och plockar från toppen. Om detta liknar valfri agil metod är det inte för att Henrik Kniberg, Kent Beck och jag har kommunicerat utan för att det är ett bra tillvägagångssätt.

Varje ärende måste ha ett unikt ID. Ett ID som inte hänger ihop med ärenderubriken. Detta unika ID måste gå att säga och skriva; jag föreslår konsekutiv numrering, 1, 2, 3...
För icke-databasssystem använder jag dagens datum följt av 01, 02, ..99 (20080118.01) för att jag brukar kunna hålla antalet ärenden idag i huvudet och har ännu inte råkat ut för fler än 99 på en dag.

Det här med en och samma ärendetyp har Microsoft Team Foundation missat. När man skapar ett ärende i det kan man välja mellan olika ärendetyper och när man har valt kan man inte ändra. TFS är konfigurerbart så man kan säkert välja bort alla ärendetyper utom en, men att det överhuvudtaget finns känns konstigt för mig.

Jag önskar mig ett ärendehanteringssystem där man får en översikt av sina ärenden mer än som bara listor med rubriker. Jag önskar mig en sorts bollar med snören emellan där man smidigt kan se vad som hänger ihop och hur mycket som påverkas om man drar i en av bollarna.


Everything is a bug. Correction: everything is an issue.
Disregarding the issue creates a crash, is the wrong image size or installation and configuration and testing of a UPS it is somethign that shall be given a human and time.

My opinion is that everything should be in the same pile. With everything I mean everything. Then the issures are prioritized and picked off of the top. I you, dear reader, now recognizes and starts looking at your books about agile project methods this is not a coincidence. I am not saying that Henrik Kniberg, Kent Beck and I have communicated but that it is a good method.

Further must every issue have a unique ID separated from the title of the issue. It must also be short enough to say and write - I suggest just numbering them from 1 and on as they are created. In spreadsheets and other non-database systems where I cannot track the unique key I usually use the format yyyymmdd-nn because one can probably store the number of issues that day temporarily in the head and I have never written more than 99 issues in one day.

Looking at Microsoft Team Foundation I say that they have stumbled regarding the everything-is-an-issue thing since there are several issue types and once you have chosen one there is no going back. To their defense I have to mention that TFS is configurable and one can choose to use just one of the types. But the very existence of non-changeable issue types is strange.

On my wish list is an issue manager where the browsing and handling of issues are outstanding. I wish of something like balls interconnected with strings and when you juggle one ball you se whatever it pulls/affects.

How long will it take

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.

To the point of no surprise

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."

Different countries separate roles differently

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.

Work with good people

This message will be repeated in english.

Jag har haft turen att jobba med bra folk. Testa det.
Bra beslut som ifrågasätt av bra människor ger ett ännu bättre resultat.


I have hade the luxury of working with good people. Try it.
Good decisions that are questioned by good people gives an even better result.

Cut features - not customer values

This message will be repeated in english

Ibland händer det att ett projekt går över tiden eller blir fördyrat av annan orsak. Då måste man göra något.
(Efter man har skurit bort dokumentationen och ner på testningen) letar man efter funktionalitet att ta bort; men vilken?

Jag vill dela med mig av tanken "Ta bort funktionalitet men inte värde."

Exempel: Kunden vill kunna välja på flera roller för varje användare som kan logga in. Värdet behålls om man kan be kunden logga in som olika användare istället (username_adm, username_op, username_reader).

Detta är inte alltid tillämpbart eftersom vi försöker ta bort funktionalitet som inte tillför något värde. Men tanken finns där.


Sometimes a project goes over budget. Then you have to do something.
(After cutting away documentation and down on testing) one looks for functionality to remove; but which?

I want to share the thought "Remove functionality but not value."

Example: The customer wants to be able to log in with one user but then to choose from several roles. Functionality is cut but value is kept if the customer is persuaded to logging in with several users (username_adm, username_operations, username_reader).

This is not alwasy doable since we have gotten quite good at removing functionality that is not needed. But the though is still there.

The wikified project

This message will be repeated in english.

<floskelvarning/>

Jag jobbade för några år sedan på ett företag där ledningen hade läst en bok och nu skulle "platta till organisationen". Det startades ett förändringsarbete och efter ett knappt år var vi nere i 2,5 lager istället för de 3 vi hade tidigare.

Vi var tydligen platta nog.

Men... koncernchefen var inte koncernchef för att han var full av dåliga idéer. Han kanske såg mer då än jag. Något jag förstår först nu. Som ingen av oss förstod då.

Gör en wiki-analogi där allting ligger på samma nivå men man länkar fram och tillbaka beroende på behov.
Jag har hittat en artikel som lättfattligt beskriver detta. Artikeln har dessutom den fördelen att den har bra rubriker och lättläst text så den är lätt att skumma.

Om du tänker mer i "projekt" än "organization" byt ut orden.

http://www.eu.socialtext.net/wikinomics/index.cgi?the_wikified_organization



<buzz word warning>

I worked some years ago at a company where the management had read a book. So we were to "flatten the organisation". The wagon was set rolling and after less than a year we were down to 2,5 layers instead of the 3 we had earlier.

We were obviously flat enough.

But... the top dog was probably not top dog because he was full of stupid ideas. He probably saw more than I. Something I understand now. Something none of us understood then.

Make a wiki analogy where everything is on the same level but the links back and forth create the patterns.
I have found an article about this. Besides begin easy to read it has good headlines so it is skimmable.

If you think more of "project" than "organization" just exchange the words.

http://www.eu.socialtext.net/wikinomics/index.cgi?the_wikified_organization

Agile

This message will be repeated in english.

Jag har hittat en artikel om Agile projekt som är kort nog att hinna läsa och oteknisk nog att förstå även om man inte är utvecklare.
Den passar alltså att ge till folk som inte förstår teknik men ändå inte gillar agile.


I have found an article about Agile projects that is short enough to be readable and lacks tech talk to allow non-developers to understand it.
Alas it is fit to be sent to people who don't understand technique but is still against or reluctant to agile.

http://www.ddj.com/architect/202401107?cid=RSSfeed_DDJ_All

When to stop debugging

This message will be repeated in english.

En artikel med en skiss på hur länge man skall debugga. Ibland skall man lämna buggen innan man har hittat den.
Detta hänger bra ihop med min syn på bug/ärende-hanterare. Skriv ner buggen/ärendet och lämna det till någon - vem som helst som kan ta buggen/ärendet vidare och fortsätt med det du jobbade på när du hittade buggen. Nu ligger buggen/ärendet i listan över saker att göra och någon kommer prioritera den.

Märk att om du däremot skall rätta buggen så skall du ta reda på orsaken och inte bara rätta symptomen.


An article with a sketch of how far you should debug. Sometimes one should leave the tracking before the bug is found.
This corresponds well with my view of how a bug/issue-manager should work. Write down the bug/issue and leave it to someone else. Now the bug/issue is in the list and it will be prioritised.

Note that if you are supposed to fix the bug you have to fix the very cause and not only the symptoms.

From the article:
"...stops debugging it and files the bug. He doesn't dig into the implementation itself to see where the memory leak is happening. He never gets to the exact cause. But, what he has done is find somebody to assign the bug to, and then he moved on..."

Rotate tasks

I have an idea of how to induce communication in a project.

I really wanted to do pair programming but didn't dare to insert it into the project due to some reasons.
After a while I noticed that even with templates to code from, people did things in their own way (naturally) and that people had different knowledge about the customer's plans.

I then thought about rotating the tasks, like one only works with a task for 2 days and then everyone switches. This forces people to communicate (i.e. ask others what they have done) and to sync their programming styles with each other.

I never forced this though.
But if anyone have - feel free to tell me the outcome.