>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.
>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.”
>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.
UPDATE 20201218: Volta never made it. Instead we today use Typescript.
This message will be repeated in english.
Så länge jag har känt mig själv har jag klagat på den svaga typningen i Javascript.
Jag kan förstå att implementationen är olika mellan olika webbläsare och nästan, men bara nästan, förstå Microsofts egocentriska volt med IE att göra en egen händelsemodell. Men jag kan inte förstå det strategiska beslutet av Netscape att göra ett svagt typat språk.
För några år sedan ramlade jag över en lösning, Script#, som kunde omvandla typsäker C#-kod till Javascript. Den var ett experiment så jag vågade aldrig ta in den i produktion och hade inte tid att leka med den. Vad jag inte visste förrän nyligen var att Microsoft har tyckt som jag.
Så nu har de lanserat Volta.
As long as I have known myself I have been irritated on the weak type model of Javascript.
I can understand that the implementation of Javascript differs between the web browsers. And I can almost understand Microsofts egocentric trick with Javascript in the earlier IE versions. But I have never understood Netscape’s reasoning behind making a language weakly typed.
Some years ago I stumbled over a solution, Script#, to convert type save C# code to Javascript. It was an experiment so I never dared to bring it into production even though I wanted to. What I didn’t know was that obviously someone at Microsoft thought like I.
So now they have launched Volta.
[Update: Bytte mjuk mot svag.]
>This message will be repeated in english.
När jag listar kontakter i min nalle börjar den alltid längst upp, på A. Varför inte börja i mitten?
Dessutom är det mer troligt är att jag vill fortsätta där jag var senast, men det är en annan femma.
When I open Contacts in my phone it starts at A. Why not start in the middle?
Then… I probably want to continue where I let off the last time. But that is the source of another posting.
>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.
>This message will be repeated in english
Någon gång i slutet av 1900-talet bestämde sig Microsoft för att slopa Avbryt-knappen på sitt nya operativsystem PocketPC.
I operativsystemet innan, WindowsCE PPC, fanns en Avbryt-knapp så om man råkade nudda kalendern kunde man alltid Avbryta sig ur att skapa en ny post. I PocketPC 5.0 som jag använder nu är det svårare att skapa en ny post men lika lätt att flytta den. På en nuddning har man flyttat ett möte i tiden och det finns inget sätt att ångra. Detta på en apparat som är gjord att användas.
Detta är lika korkat som när Apple tog bort den andra knappen på musen de hade under ett kort tag.
Sometime in the end of the 20th century Microsoft updated their WindowsCE PPC to PocketPC. At the same time they removed the Cancel button.
I refused to buy a new gadget when you were just one tap away from moving your appointment without having any way to cancel you erroneous tap. I mean, it was built to be used in other places than a steady desk, right? What where they thinking of?
And with PocketPC6.0 the Cancel button is still missing. This is as stupid as when Apple removed the second mouse button they finally got in place.
>This message will be repeated in english.
När man jobbar med use case är en av parametrarna de olika typerna av användare. Med dem håller man reda på att man bygger rätt sak för rätt roll.
Härom dagen snubblade jag över ett ärendehanteringssystem, ni vet ett sådant som helpdesk/supporten använder. Där kunde man sätta prioritet på ett ärende men vi skulle nogsamt undvika prio 1; för med prio 1 gick det ebrev till en hel hög med folk, bl.a. högsta chefen.
Jag skulle vilja höra den felrapporten.
“Hallå, är det helpdesk? Jag skulle vilja rapportera ett ärende.”
“Ja. Vad är det om?”
“Fabriken brinner.”
“Ok. Noterat. Hur bråttom är det?”
“Görsketabråttom, så det är nog bäst du sätter den på prio 1. Chefen vill nog veta.”
Hur mycket jag än tänker kan jag inte komma på ett supportärende som kräver att chefen behöver veta men inte är allvarligt nog att jag kan ringa honom.
One of the parameters when working with use cases is the different types of uses. They are used as guidance for building the right thing for the right role.
The other day I stumbled over a issue system, you know the kind helpdesk/support uses. One of the values to set was priority but we were asked not to use priority 1 because then an email was sent to more or less everyone including the top boss.
I would like to hear that report.
“Hello. Is it help desk? I would like to file a report.”
“Yes hello. What is it about?”
“The factory is on fire.”
“Ok. It is noted. How urgent is it?”
“Very urgent I believe. So please give it a priority 1. The boss probably wants to know.”
I have been thinking about it but have still to come up with an issue that is important enough to the boss to know but not serious enough to just call him on the phone.
Since many years – many years before I noticed it – has it been possible to dump the text of a message box with ctrl-c.
Example: an application throws an exception and a dialogue with an error message pops up. Instead of dumping the screen and attaching the picture file just copy the text with ctrl-c and past it in you email.
>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.