Disqus - Latest Comments for jhannes

Re: The Malmö Experiment: Estimation Techniques Shootout

jhannes — Tue, 10 Nov 2009 13:34:05 -0000

Hi, James

Great comment, name and link. A small question: You say it works well for "a large number of stories". How large is "large"? Your pictures look like 30-40 stories. Is this the comfortable range?

Re: Extreme Integration: The future of software development?

jhannes — Sat, 15 Aug 2009 12:58:31 -0000

Thanks for insightful comments and links. The Enterprise Continuous Integration chart was interesting. Do you have more information on the specifics of the Reporting row?

I agree that testing is the big barrier. It is what requires improvements in practice, not just tools, and that's always harder.

I'd also like to hear your thoughts on the auto-checkin and checkout ideas I outlined.

Re: Extreme Integration: The future of software development?

jhannes — Wed, 12 Aug 2009 10:25:43 -0000

Thanks for your comments and insights, Bjørn. I should examine TeamCity more. Probably not to use it, but to see what it feels like.

Re: Extreme Integration: The future of software development?

jhannes — Wed, 12 Aug 2009 10:23:33 -0000

No sweat! We can fix the above description with very little hardware. At least if you seize control of the app server.

Re: En lynrask innføring i Scrum

jhannes — Mon, 10 Aug 2009 08:32:12 -0000

Takk for gode innspill.

1. Skal bruke ett ord for sprintkø og iterasjonskø i neste iterasjon (=> sprintkø)
2. "Et stå-opp-møte holdes hver dag, ofte om morgenen, for at teamet skal kunne koordinere fremdriften på iterasjonskøen." => "Teamet avholder et stå-opp-møte holdes hver dag for å koordinere fremdriften på sprintkøen. Møtet holdes gjerne på morgenen og ved tavlen der sprintkøen er dokumentert"
3. Jeg tror jeg skal utelate knepet med rosa lapper og heller vurdere en "Slik forbedrer du ditt Scrum-prosjekt" med tips og triks.
4. Jeg plasserer herved en TDD-guide på min personlige produktkø

Re: En lynrask innføring i Scrum

jhannes — Thu, 06 Aug 2009 17:03:03 -0000

Bra linker. Jeg skal i alle fall ta med Schwaber/Beedle-boka og kanskje Mike Cohns nye bok i neste versjon. Jeg burde vel også nevne http://forum.smidig.no, Oslo XP meetup og Oslo Lean Meetup.

Re: Is Steve Jobs really a benevolent dictator?

jhannes — Thu, 06 Aug 2009 17:01:28 -0000

Thanks for the link. Another story to add to my #badapple file. :-)

Re: En lynrask innføring i Scrum

jhannes — Wed, 05 Aug 2009 14:27:56 -0000

Takk for positiv omtale! Jeg hadde noen linker i kladden, men de falt ut underveis i prosessen. Har du noen linker du vil anbefale?

Re: Book review: Breaking the Spell

jhannes — Fri, 24 Jul 2009 13:36:06 -0000

I'm not sure it's a positive application. :-)

I think we might often be saying "we have to agree on something (e.g. SOA or Agile), even if it doesn't work". This is close to believing in belief. But I don't think that holds water. Our ideas need to pull their own weight. Otherwise, they will get in the way of what really does work.

Re: Book review: Breaking the Spell

jhannes — Thu, 23 Jul 2009 05:15:42 -0000

That is a very interesting idea. I guess the analogy would be if we though that it was unknowable if XP, Scrum or OpenUP or whatever gave us benefit, but we still think it's useful to have a methodology in order to have a direction.

Similarly, we could think that if we choose SOA or REST or DDD that won't make a big difference. But choosing one architecture will give us a common purpose.

I guess "belief" is a certain methodology, architectural style or framework. "Belief in belief" would be to say "we need a framework, even if it doesn't give us a direct benefit, so that everyone is aligned the same way."

Is this what you had in mind? Is this "belief in belief" prevalent?

Re: Unit testing tricks: Look ma, no setters!

jhannes — Wed, 17 Jun 2009 12:42:40 -0000

True. The reason they ended up as protected is that that's what happens if you just do "Ctrl-1" in Eclipse. ;-)

This example requires a no-arg constructor, but if Account only had, say, a constructor "Account(String accountNumber)", you could just do new Account("12345678901") {{ and the rest would be the same.

Re: Unit testing tricks: Look ma, no setters!

jhannes — Mon, 15 Jun 2009 05:45:05 -0000

Yes. But I thought that'd give me as much violation of encapsulation, but with more code. If the setters were to be used by other code, I would've gone that way, though.

Re: Unit testing tricks: Look ma, no setters!

jhannes — Sun, 14 Jun 2009 16:19:15 -0000

The impact on the class under test is something that concerns me. In this particular case, we were debating whether to do this or use a inner builder class. They both felt slightly smelly, but at least this approach has the least code.

When the problem starts to scale, I might consider builders, structs, introducing setters or something else. But it seems like a lot of extra code to write for the size of the problem.

There's a lot of tools in the "object initialization in test" toolbox. I'm still not thrilled with any of them.

Re: Unit testing tricks: Look ma, no setters!

jhannes — Sun, 14 Jun 2009 14:22:56 -0000

This is indeed a tricky tradeoff. (However, I don't think I'd set the *fields* public to support tests!)

We use Account.createAccountWithBalance() for similar cases. But when we found that each test needed to setup about 5 of 10 possible fields (different 5 for different tests), factory methods started to become confusing as well.

The tradeoff between a complex factory method and this trick is that the {{}}-trick is harder to understand the first time, but it's usually easier to read when a number of fields are being initialized (as opposed to remembering the position of each factory method argument).

Then there's the inner builder pattern....

Re: Unit testing tricks: Look ma, no setters!

jhannes — Sun, 14 Jun 2009 14:17:57 -0000

account.Deposit is a good option in this case. The trade-offs are that this function may not exist in your system (which is my situation) or that it may have side-effects which may then affect this test. If neither is the case, it's probably a better approach.

Mocking is a tool I try to stay away from as it, too, can lead to tight coupling between your test and accidental behavior.

I think the {{}}-trick is only appropriate in very specific circumstances.

Re: Unit testing tricks: Look ma, no setters!

jhannes — Sun, 14 Jun 2009 13:58:05 -0000

In theory, this is a valid concern. In practice, you can't really get around it. If you consider the example tests: How can you test this functionality without being tied to the fact that the account has a balance?

Re: Guidelines for eGovernment Projects

jhannes — Thu, 04 Jun 2009 16:27:22 -0000

Hi, Glen

Thank you for your follow-up. These are very important issues with a checklist and I agree with your evaluations of all of them.

Re: Vær-varsom plakaten for arkitekten

jhannes — Thu, 28 May 2009 16:34:32 -0000

Bra innspill. Å bare starte med #1 er en god start for mange.

Re: Den Smidige myte?

jhannes — Thu, 28 May 2009 15:07:41 -0000

Hei, Magne

Synd at vi misforsto poenget ditt. Vi har jo tidligere diskutert hvor vidt det kan besvares om "gyldigheten av" smidige metoder er eller kan holde vann vitenskaplig, så dette farget hvordan jeg leste artikkelen din.

Jeg husker ikke nøyaktig detaljene fra foredraget ditt på Software 2009, men jeg oppfattet at du der rettet kritikken mer direkte mot påstander om smidige metoder. Finnes slidene dine fra dette foredraget tilgjengelig noe sted?

Re: PodCast: I discuss FitNesse with Uncle Bob

jhannes — Tue, 26 May 2009 17:07:22 -0000

In the PodCast, Bob mentions Parnas tables as an inspiration for FitNesse table structures. A good place to start if you want to know more about this classic technique for requirement specification is this presentation: http://watform.uwaterloo.ca/Pubs/AtleeDLPS.pdf

Re: Vær-varsom plakaten for arkitekten

jhannes — Fri, 01 May 2009 14:54:21 -0000

Du har rett. Jeg gjør nok møter feil. Kanskje jeg skulle gå på et møte for å lære hvordan å gjøre møter bedre. ;-)

Det er måter å gjøre møter bedre på. Jeg har funnet et par knep, men har følelsen av at jeg bare har skapt i overflaten.

Re: Vær-varsom plakaten for arkitekten

jhannes — Tue, 28 Apr 2009 12:16:33 -0000

Jeg forblir gjerne ekstrem når det gjelder møter. Jeg tror over 2/3 av de møtene jeg er i er bare bortkastet tid av noen som trenger å føle seg viktig. Jeg har selv vært skyldig i dette, og prøver å bli bedre.

Nå har jeg en litt spesielle setting: På mitt nåværende prosjekt er veldig mange av mine teammedlemmer veldig flinke til parprogrammering. Vi har også mulighet til å ta veldig mange avklaringen med produkteier, domeneeksperter og tekniske eksperter på sparket når problemstillinger dukker opp.

Dersom man ikke har en slik kultur, er det nok en større andel av møtene som har verdi.

Bra poeng med å stille ledende spørsmål. Men selv det antar at du allerede vet hva som er beste løsning. Se vær-varsom plakaten om "vær forsiktig med å foreslå løsninger." ;-)

Re: Vær-varsom plakaten for arkitekten

jhannes — Fri, 24 Apr 2009 13:04:58 -0000

Kanskje en mulighet er å reformulere det som et spørsmål: "Er dette møtet nødvendig for fremdrift? Nei? Da skjer det i stedet for fremdrift". Jeg liker ikke helt spørsmålsformuleringen.

Hva med "møter som ikke hjelper fremdrift stjeler tid som kunne vært brukt til fremdrift"?

Re: Vær-varsom plakaten for arkitekten

jhannes — Thu, 23 Apr 2009 11:41:32 -0000

Godt poeng. Jeg har vridd hodet mitt etter en mindre ekstrem formulering som ikke mister snerten. Har du noen ideer mottas de med takk.

Re: Refactoring on @Ignore

jhannes — Sun, 05 Apr 2009 10:50:38 -0000

"If you step into the swamp, take a step back". Love it!