Skip to content


Trying out some retrospective techniques

At the latest retrospective, I tried out a couple of new techniques which was fun and interesting, but I need to change a couple of things next time.

I started out with the team thermometer (by Jimmy Janlén). I used the five original questions which worked fine as conversation openers. I asked those with the lowest and the highest grade on the questions what made them give the grade, and found positives to keep and things to explore further. But next time I need to change the following:

  • Fewer people. Now I did the retrospective for two teams simultaneously, next time split it in two retrospectives.
  • The excel template provided did not work on Mac

Next I had a break and gave 5 minutes for own reflection to write down anything additional they wanted to address.

After that, we went through the issues. First we talked about the good things. Next about those that could get better. Then we dot-voted to get a priority. For the one that got the highest votes, we did the force field analysis.

With the force field analysis, I had an open discussion. But it would have been better to do it in groups. The groups discusses forces that drags us from the goal and forces that drags us towards the goal and then presents to the whole group.

Finally, dot-voting on the things that would drags us towards the goal and taking one or two as sprint improvements.

Posted in Agile, Retrospective, Scrum.

Tagged with , , , .


Achieving hyper-productivity

Extremely interesting article about how to kick-start a team into hyper-productivity.

Posted in Agile, Leadership, Scrum.

Tagged with , , .


Why JSTL tags doesn’t work

The JSTL (c: ) tags are problematic. I have had problems with, for instance c:if and c:foreach not doing what I thought they should. Here is why!
Continued…

Posted in JSF, Programming.

Tagged with , , .


Advanced Agile with Alistair Cockburn – day 1

So these are my takeaways from the first day of attending Alistair Cockburn’s Advanced Agile course

The further away you are from the code, the more afraid you get. The more afraid you get, the more reports you request. The more reports yuo request, the more work you impose on those trying to write code. Having demos reduces that risk at least.

[picture of practices, theory, self awareness stair] You move between the steps, but never two steps at a time.

Advanced Agile is when you know why it works (not just that it works).

shu-ha-ri;
shu: follow, learn one technique
ha: collect techniques
ri: invent techniques – you do not reflect upon what technique you use, you just use it.

You cannot be at the ri-level and be self-aware about it.

You must be able to tell other the negative sides of agile, since there of course are. If you do not, you’re doing dogma.

You don’t ”fail fast, fail often”, you learn (by dong mistakes).

Excercise:  ”Things that slows down the movement of ideas between minds”. Alistair argue that the pace of the project is how fast ideas can move between minds. So by removing things that slow that down, the project can move faster.
So take a session at a retrospecive, or a team building day, and make a sticky notes session about this. Discuss the ideas that came up and see if there is anything that you can implement.
For example, language, time zones, distance, walls, knowledge, etc. affects the speed.

Sometimes it is not best to co-locate. Sometimes it is better to keep your most important resources out of touch, so they can bog down and just code.

[picture of knowledge over time agile vs waterfall] In waterfall, you learn things after a long time has passed in the project. Doing integration late, testing late, getting user feedback late. In agile, you do these activities every sprint, sometimes several times per day (CI or CD for instance). That results in gaining knowledge very fast throughout the project, until all the major risks have been mitigated. Then the learning curve decreases.

[RBT picture] The learning curve in an agile project goes up the most in the beginning of the project, and then decreases at the end, where you are polishing the product. So the project can be divided into a risk-, business- and tail-phase. The same can be said of a user story itself. So You can divide a user story into a risk-mitigating part, a business (or bulk) part and a tail part where you add the chrome lists (if any).

 

Posted in Advanced Agile.

Tagged with , , , .


Rename in Eclipse

Ever had problems with renaming a method or variable in Eclipse? Sometimes Eclipse tells you that some files ”are out of sync”. Now, this is easily fixed simply by refreshing (pressing F5) the project the file your are working on exists.

Posted in Programming.

Tagged with , .


Emergent design – JFokus day 3

Neal Ford’s talk on emergent design at JFokus 2011 day 3.

It is not a binary state between being agile and being water fallish. It is a gilding scale.

Find abstractions and patterns. Not GoF patterns, but idiomatic patterns. There is a difference between technical patterns and domain patterns. Technical patterns are for instance validation, security, transactions. Domain patterns are business rules, shared functionality.

Martin Fowler described architecture as ”the thing that is difficult to change in the system.” And it should be as little as possible of that (but not less).

Why is emergent design difficult?

Complexity. Remove accidental, keep essential.

Technical debt. Business moves faster than software. Therefore there is a risk for accumulating technical debt, and you need to negotiate repayment. One way of doing that is to show the technical debt, by combining cyclomatic complexity and Afferent coupling

Rampant genericness. By adding genericness to your system, e.g.  trying to make frameworks, you add to the complexity of the system by increasing the code base. This adds to your accidental complexity. You pay for the genericness from the second you check it in, but you don’t get anything back until you utilize it.

Things that help you with emergent design.

TDD – Not only Test Driven Development, but also Test Driven Design. Think Clean code, small methods, methods that only do one thing.

Refactoring

  • Collective ownership of the code
  • Remove broken windows
  • Note that the IDE only refactor by making a new method with lots of parameters. This is not always the best way.

Posted in Architecture.

Tagged with , , , .


Top SOA tips – JFokus day 2

Top SOA Tips – A Road to a Successful SOA Implementation, a presentation from Jeff Genender. This was a very good presentation of things to have in mind when entering a SOA project.

Think big – start small

SOA Governance

Choose your weapons – and govern them

  • One tech/tool doesn’t solve all problems

Know thy basic SOA patterns

  • soapatterns.org
  • eaipatterns.com
  • refcardz

Version early – version often

  • Backwards compatibility
  • Services must know which version they are and tell their surroundings

Be as asynchronous as possible

  • If not, risk of hanging threads

Watch your XML/soap use

Design with right granularity

  • Not too small or too large services

Point to point is bad

  • Results in push architecture instead of pull
  • You want a router instead to have greater flexibility

There is no right way

  • Trade-off between needs/technique/organisation

Every pattern is an anti-pattern somewhere else

Posted in Architecture.

Tagged with , .


Unsorted findings from JFokus 2011

Real vs. accidental complexity. Accidental complexity is for instance when we add speculative functionality, BDUF, or similar. The more complexity the harder to add or change functionality, the lower velocity on the team.

Git – ambientideas.com/blog

”We got to get the model right before we start coding.” No, modeling is learning and we will not get it right the first time. So if we think that the model is dine done the first time and start coding, what we really do is to build in the most amount of errors in the software. Eric Evans, DDD

Modeling and design is the quickest way to the goal.

A domain model is a system of abstractions representing selected aspects of the domain. Eric Evans

JBoss AS 6 starts in 20 seconds, JBoss AS 7 in 0,5 seconds.

Weld is the reference implementation of of CDI.

Java EE 6 works on Glassfish 3.1 and JBoss AS 6.0

Posted in Architecture, Programming.

Tagged with , , , , , , , .


The productive programmer – JFokus day 1

The first session I visited at JFokus this  year was Neal Ford’s the productive programmer. His presentation was from his book The productive programmer, which I haven’t read (but I might now).

The presentation was about both the little things and more philosophical discussions on how to become more productive as a programmer. I have heard and use most of it already, but it is never out of place with a reminder. Here’s the summary:

Accelerate

  • Graphical user interfaces are slow. I. e. using the mouse is slow. Learn the short cuts and use a shell instead.
  • Check out windows explorer address bar (ctrl-d)
  • Check out the number fox plug-in
  • clcl – a clip board extension to windows to get more than one clip board
  • Context switching eats time
  • Command prompt here power toy
  • Bash here
  • Command prompt explorer bar
  • Mouse feed for eclipse
  • Read through Eclipse help and make a cheat sheet of short cuts you find useful
  • Make templates for recurring things you do
  • Use the auto-hot key

Focus

  • To remove annoying Windows baloon tips: Tweek UI
  • Screen dimmers: Jedi concentrate
  • Google desktop search with any text file plug-in
  • file explorer rooted view
  • Use virtual desktop (virtua win)

Canonicality

  • DRY principle
  • Use subversion plug-in to export check-in comments via RSS
  • Schema spy for getting a graph of the database

Automation

  • One command build. Not several steps to build the system
  • CI
  • Remove commented out code, if you need old code it is in the version control system.
  • Selenium IDE – record scenarios to reproduce bug situations
  • Bash script for reading through log files
  • Solving problems by hand makes you dumber. Automating instead builds assets which makes you smarter.

Don’t shave yaks!

Composed method

  • One method only responsible for one thing. This makes the method shorter and clearer – clean code book…
  • GoF template method
  • Works fine with TDD

TDD

  • Think of it as Test Driven Design instead of Development

Static analysis

  • Findbugs
  • PMD – source code control
  • cpd – copy paste detector

Good Citizenship

  • Do not always generate get/set-methods, keep encapsulation
  • You do not need to unit test get/set
  • When handling objects – go from one known state to antoher. immutable objects.
  • Only use static methods on stateless objects

Yagni

  • You Ain’t Gonna Need It
  • Do not make premature assumptions/descision like BDUF
  • Only do what needs to be done right now

Slap

  • Single level of abstraction
  • Combine with Composed Method
  • Makes the code more readable

Polyglot programming

Use different programing languages for different problems.

Posted in Programming.

Tagged with .


Showing off your SVN revision number in your web application

If you have serveral different environments to which you publish your web application, a common problem is to know what version of the application is installed in which environment. The solution to this is to publish the version number somewhere. But you want to automate the process. This is how you do.

Continued…

Posted in Programming, Tools.

Tagged with , , , , , .