Archive for the ‘Methods and Leadership’ Category

When code reviewing – do not forget to give appraisal too

September 29th, 2016

Albeit code reviewing is for the greater good and we all adhere to the idea of common ownage of code we are still critisising someone else’s labour.

Psychologically we cannot neglect that.

Ergo: remember to tell about the good solutions and code you find.

Unfortunately TFS does not have a (good) solution for differentiating between comments and praise and critisism.

Incremental vs completionist problem solving

October 21st, 2015

Do you solve the problem one step at a time, slowly ever going forward, but without the final goal?
or do you see the goal and work steadily towards it?

Of course you do both but might be biased.

Below is a readworth article about this.

http://randsinrepose.com/archives/incrementalists-completionists/

Bra kommentar om teknisk skuld

October 5th, 2015

Den hyggligt korta artikeln delar upp teknisk skuld i flera delar: programmeringsskuld
, designskuld, testskuld och  kunskapsskuld. Jag tycker det var lite onödigt komplicerat; men samtidigt upplever jag det gav en möjlighet att diskutera. T.ex. vet jag ett projekt som klarar sig bra på allt utom kunskapsskulden. I och med att uppdelningen gav mig möjlighet att prata om, just, kunskapsskulden utan att blanda in all annan teknisk skuld tyckte jag att jag fick fram det jag ville säga.

Sedan undrar jag om man skall räkna in de andra skulderna i teknisk skuld.

Vidare undrar jag om “skuld” är rätt ord eftersom det är något man, förhoppningsvis, kan amortera bort. En teknisk skuld kommer aldrig försvinna för när man kommer närmare målet ökar man bara sin ambitionsnivå.

Ursprunglig artikel.

The X-Y-problem

July 31st, 2013

Try to solve X.
You recognise that to solve X you must first solve Y.
You ask for help on how to solve Y.

When you really should ask for help on how to solve X.

More thorough explanation.

I have not solution to the problem but knowing it exists is a good start to avoid it.

There are mainly 2 ways to keep a running project running – change or not

July 31st, 2013

When a project goes live it enters the maintenance phase. Further development changes.

There are mainly two ways to keep said project running.

Great wall of China

The first is to pretend the world is not (r)evolving and keep the project in a stable state.
This means one must consider present and future changes and make sure these don’t affect the system.
Unfortunately this also means changes are slow and expensive; not necessarily because of code base but of management who believes the system will work and not have to be changed because changing costs money.

What often happens is that changes are postponed until a bug or security issue surfaces in the OS, underlying framework and changes must occur. Note that I wrote “OS” and “underlying framework” and not the project specific code. The world did (r)evolve despite intentions.

Continuous change

The other method is to acknowledge that the world changes and change accordingly. The world changes continuously so allow the project to change continuously.

What comes out of this is also that every change becomes cheaper, both in money and in administration and in percieved load for management. Bugs and features are also fixed and implemented faster which benefits the business.

Microsoft team foundation bug management

June 20th, 2012

A minute ago I reported two bugs for a project and noticed that the GUI for bug reporting in TFS inside Visual studio still sucks.  It sucked 5? years ago.  It still does.

It was a flashback because I 1) didn’t remember exactly how user unfriendly the form is with edit fields all over, hard (partly impossible!) to navigate with keyboard and bad overview.  There wasn’t a clue 5 years ago that a bug had an attachment.  There still isn’t.  2) didn’t remember how awfully slow it was.  Reporting bugs might inflict some stress to me because there is so much I want to tell but text and images are so limited and I want to get it all out before it flees my mind.

Now I can see that the overview of bugs is still lousy.  I have read that it has improved but from what?  To Microsoft’s defense I must say that they have done a good effort but it all smells like one-department-for-testing with dedicated-testers and one-department-for-developers and so on.  To me development, testing, operations, architecture is all the same.

So even though I like the symbiosis of TFS and VS and the whole test rig with virtual machines one can buy from Microsoft I won’t sell the bug management tool to any client that isn’t already deep into it.
The licensing model, as I remember it last time I checked, also bothers me but that is for another article.

Shanzhai

February 28th, 2009

In the west we are raised in a strong belief that everything can be owned; written text, images and even land(!)  With this belief as our Pen and money as our Sword we push this way of thinking on the rest of the world so as to keep our wealth.

Not everyone has this same belief and are happy to invent and reinvent former inventions and constructions instead of protecting the old.  One word for this is plagiarism, another is Shanzhai.  I am afraid a new word will be “economic terrorism”.

If I claim that others follow my rules then I should be prepared to follow theirs; I am not automatically right because I have a bigger gun.

http://www.bunniestudios.com/blog/?p=284
http://online.wsj.com/article/SB123257138952903561.html

Postpone decisions

February 27th, 2008

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 earlier than that.

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

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

No information is better than wrong information

September 13th, 2007

With no information you have one task.
1) deduce the right information

With the wrong information you have to:
1) understand the information
2) find out that the information is wring
3) deduce the new information

Total Quality Management with software

June 5th, 2007

>If you (the reader) is familiar with TQM the following three rows should be familiar:
Don’t inspect quality in.
Constantly improve the system.
Break down barriers between departments.

If you are not familiar with TQM it is perhaps the reason Japan’s industry creates things faster, cheaper and better than the west. Deming is a name to remember for this.

Now… what can we learn from this?

Don’t inspect quality in.
In a large enough project there are special testers that apply their magic when the code already is written. Wouldn’t it be nice to not write the bug in the first place?

Constantly improve the system.
When did you last look over you development method? Your debugging method? Your deployment method? There is even a book written about it called Debugging the Development Process.

Break down barriers between departments.
Does your project have “programmers”, “designers”, “architects”, “testers” and “project leaders”? Why does it? Because the need arouse or just because that is how it was done last time?

The inspiration for this article was found here.