Archive for the ‘Methods and Leadership’ Category
August 10th, 2017
If I ever get around to writing The bug management system (one that works as good as for instance Stack overflow) I hope to have the bugs classified as Bohrbugs, Heisenbugs, Mandelbugs and Schrödinbugs.
Praise where praise is due.
On a side note I don’t mean a bug should be categorised into one of the types above. It should, if applicable, be tagged with one or more.
This I say because I believe a bug is not a bug but a task. Everything is a task.
Then in my stupendous system I would not call it a task but something without meaning. “radish” “kopannkaka” “thigglymijig” “kuto” “item”
June 17th, 2017
The question is not “Can you do x before month’s end?”.
The question is “Can you remove something that is less important than x?”
In an earlier project I had all my tasks on a wall so when someone wanted a task done they had to physically remove a note and instantly knew that another task would not be done (until something else was done or removed).
To put even more stress on the person, let’s call him Andersson, wanting to allot some of my time the notes/tasks had different owners. This meant that Andersson got a physical feeling that his/her work was more important than someone else’s.
“Do you think I can remove Svenssons note?”
“I don’t know. Ask him.”
This meant I didn’t have to switch task and search out Svensson and present someone else’s task and then come back to Andersson with a result.
Andersson understood his/her action had impact on two other people. Andersson’s problem was still in his/her hands.
My time spared. Svensson’s time spared.
Andersson didn’t have to wait for a decision from someone else.
All win.
June 2nd, 2017
I am presently using TFS’s code reviewing tool and IMHO it lacks visualisation of which comments are important and which are not.
So I came up with the idea of prefixing my comments.
PRAISE: Good refactoring, I like how you remove the negation.
FIX: A null check is missing.
SUGGESTION: Split line.
CHECK: Is it the right enum used here?
EXPLAIN: Is this comparison really correct? or seems to overflow to me.
If there are many FIX but only one or a few are critical I prefix the critical once with RED, like RED FIX.
This gives the opportunity to “while you already are updating the module, do these things too”.
When code reviewing do not forget to give appraisal too
Update:
This is what I wrote at Patricia Aas’ show at Dotnetrocks:
I have learned that some don’t like code review because it is a critique of the code written. When failing a code review the task is halted for a rewrite and everyone loses.
I love it because to me it is a discussion about code and the system *we* are building *together*.
The code involved is a talking piece.
I prepend my comments with “PRAISE:”, “FIX:”, “SUGGESTION:”, “EXPLAIN:” and “CHECK:”.
FIX is the only one failing a code review.
Depending on the amount of, and severity, EXPLAIN and CHECK might give a red flag too.
The rest are for discussion; to learn and spread knowledge.
PRAISE is important. Only giving negative critique wears a relation. It might also be a part of the reason some don’t like code reviews. It can be hard to recognise good code as, as with many things, it steps out of the way so one does not reflect upon it. Good naming of a method, remember to remove old usings, good test data, …
SUGGESTION is how *I* would like to write the code. Change if you like, don’t if you don’t. I’d be happy to talk about it but there is no need to involve me in a decision.
EXPLAIN on the other hand requires my input. I don’t understand what you are doing – please explain it to me. If it is easy to explain then I should probably have understood; but if you have a hard time explaining it, then there is a good chance the code is too complex. (I have found a bug this way.)
CHECK is more serious. I am not sure you are doing the right thing and would like for you (or anyone else, including me) to double check it.
Typically there will be quite some SUGGESTION followed by a healthy amount of CHECK and EXPLAIN.
Update:
I have used this method for some projects now and only received positive or neutral feedback.
In one project one colleague took every SUGGESTION and implemented them while another ignored anything that wasn’t FIX. Both were skilled and made good choices. We talked a lot about code.
In another project my colleague liked to start with only looking at FIX to get a tally and then read through the rest. S/he is/was junior and we’ve had good discussions about code.
Update:
Someone else has come to the same conclusion: https://conventionalcomments.org/#labels
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.
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/
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.
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.
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.
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.
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