Change Based Configuration Management
The simplest advanced branching strategy
Configuration Management (CM) is crucial to any software project as neglecting it will easily get you in big trouble. It may look like bad luck, but it is not.
A CM-plan will deal with several matters, from simple to decide things, such as naming of releases to more advanced subjects, such as branching strategy. I will talk about the latter today.
There are of course different ideas about what a good branching strategy should be. It is my firm belief that it must be aligned with the subject at hand, namely changes.
A CM-plan will deal with several matters, from simple to decide things, such as naming of releases to more advanced subjects, such as branching strategy. I will talk about the latter today.
There are of course different ideas about what a good branching strategy should be. It is my firm belief that it must be aligned with the subject at hand, namely changes.
Beyond Basic TDD
Where are you now?
This coming spring we will host a course with Robert C Martin on advanced TDD. I would really appreciate the input from my experienced TDD readers on what they consider to be the largest obstacles when it comes to TDD. This is your chance to shape the event so that it is customized to meet your needs.
A few months ago we hosted a very popular course with Michael Feathers. He talked about refactoring legacy systems and of course, unit tests which are an essential part of that. But the crowd cried out for more.
I have been practicing TDD for two years. I program in Java and frequently use Mockito and Wicket. The latter has support for unit testing web interfaces and it is great although it has its quirks.
But what is everyone else doing?
A few months ago we hosted a very popular course with Michael Feathers. He talked about refactoring legacy systems and of course, unit tests which are an essential part of that. But the crowd cried out for more.
I have been practicing TDD for two years. I program in Java and frequently use Mockito and Wicket. The latter has support for unit testing web interfaces and it is great although it has its quirks.
But what is everyone else doing?
Not the Fixed Price Contract
Happy Together
The fixed price contract has been discussed here at the Crisp blog by others. It is broken by design as it creates more problem than it fixes.
On the way from JAOO I talked to Udi Dahan and that made it fall into place in a different fashion. Not that this is what he said, this is what he sparked.
The fixed price contract is not necessarily fixed price, a contract or evil.
On the way from JAOO I talked to Udi Dahan and that made it fall into place in a different fashion. Not that this is what he said, this is what he sparked.
The fixed price contract is not necessarily fixed price, a contract or evil.
Design Principles for Error Handling
I Said Principles
Besides understanding the most important structures of a system, it is an architect's responsibility to understand and influence the design principles.
One common and important set of principles are those of error handling. It is good to have the same principles throughout the system as it produces fewer surprises and mistakes.
In this post, I will discuss some principles that including checked exceptions and Null Object, which you may not fancy. But it is always good to think this subject through, so please come along.
One common and important set of principles are those of error handling. It is good to have the same principles throughout the system as it produces fewer surprises and mistakes.
In this post, I will discuss some principles that including checked exceptions and Null Object, which you may not fancy. But it is always good to think this subject through, so please come along.
The Last on Code Review
How fun are you to be with?
Code quality. It has been haunting me for so long I forgot when I started to think about it. Do other people think about it? For sure. Do everyone? Certainly not.
I was doing RUP and before that some waterfall process from DoD. Before that I was programming Fortran. Now, what has been my single most important recommendation for reaching code quality?
Peer code review.
But enough. It just struck me how much I do not miss code reviews.
I'll tell you why and I'll tell you what is the replacement, because there should be one.
I was doing RUP and before that some waterfall process from DoD. Before that I was programming Fortran. Now, what has been my single most important recommendation for reaching code quality?
Peer code review.
But enough. It just struck me how much I do not miss code reviews.
I'll tell you why and I'll tell you what is the replacement, because there should be one.
Modal Windows Considered Harmful
Cornering the user is bad style
On the Wicket user's mailing list there was a question about modal windows and it set me off. Since my excellent wisdom ;) is larger than just modal windows and Wicket, I thought that it would be of interest to all of you, dear readers.
I have discovered that the modal windows that was gone when web applications started to spread, are starting to come back. And they are bad, even if they are not as bad as the goto statement that was accused the same way as I just did: harmful.
A modal window is something that pops up in the face of the user, screaming its importance by not letting the user touch anything else until the modal window had its way.
I have discovered that the modal windows that was gone when web applications started to spread, are starting to come back. And they are bad, even if they are not as bad as the goto statement that was accused the same way as I just did: harmful.
A modal window is something that pops up in the face of the user, screaming its importance by not letting the user touch anything else until the modal window had its way.
Stable Interfaces - any good?
Stability for your flexibility
I once worked in a rather large project, about 1000 persons. There are many stories about that project but the one that I'm thinking of now is that we loved to say "stable interface, we must have stable interfaces".
Now, stable means not changing which means nothing gets better. So why would anyone want stable interfaces? And what should we say about the opposite, "unstable"?
Stable interfaces is a cornerstone in tactics for modifiability, so how do stability and modifiability go hand in hand?
Do you see my finger?
Now, stable means not changing which means nothing gets better. So why would anyone want stable interfaces? And what should we say about the opposite, "unstable"?
Stable interfaces is a cornerstone in tactics for modifiability, so how do stability and modifiability go hand in hand?
Do you see my finger?
Requirements Specification is Waste
Time to Talk about Emperor's Clothes
Eclipse trashed some code for me today and I had to recreate the workspace. On such days, I can get a bit edgy and maybe I was, when commenting Richard Kronfält's blog on Scrum and traditional QA.
Sorry about that, Richard, but you are a viking so I guess I can get away with a glass of mjöd if I ever bump into you.
But my point is still, requirements specification is waste. It follows from that the issue tracking is as well. Well, not always.
Mock the Clock
Take Time to Throttle Testability
Your unit test should have no dependencies on anything external, you know that already. So you try not to read any files or connect to a database server. But what about time? Recently we had some unit tests that failed during nightly build due to daylight saving. Suddenly the distance between two days was 23 hours.
But it doesn't stop at unit tests. System tests, too, may depend on time.
You should have a strategy for how your system perceive time. Read on.
But it doesn't stop at unit tests. System tests, too, may depend on time.
You should have a strategy for how your system perceive time. Read on.
Understanding a System
What do you do to understand?
I teach a course on System Architecture. It is a three-day course attended by experienced developers who want to go further in some respect.
What strikes me most is that the majority has never read any architecture document. Since writing such documents is one of the main topics of the course, I have a long road for them as they haven't read any.
So, when you are faced with a system that you are about to change, how do you go about to understand it?
What strikes me most is that the majority has never read any architecture document. Since writing such documents is one of the main topics of the course, I have a long road for them as they haven't read any.
So, when you are faced with a system that you are about to change, how do you go about to understand it?
A Lean Simulation in JavaFX
Nothing beats visual models
My collagues are talking a lot about Lean these days. I thought it would be interesting to simulate one of their examples using JavaFX.
Here is a picture:
Here is a picture:
Don't let Java ruin your JavaFX
The new kid on the block is not thread safe
Me and Oscar is currently working on a small project, just to learn JavaFX.
We stumbled on some nasty crashes which we at first did not understand.
ArrayIndexOutOfBoundsException? Is there a bug in JavaFX?
It turned out to be a callback from Java. Let us see how we got there.
Essensen och kruxet med testdriven utveckling
Du vet att du borde men orkade inte
När du förstått poängen med testdriven utveckling kommer givetvis krånglet. Så hur tar man sig vidare?
Vi börjar med poängen så att vi är överens om vad vi menar.
Testdriven utveckling (TDD) säger att man först skriver ett test som fallerar (viktigt), sedan implementerar man så att det inte längre fallerer.
I det läget tar man sig en funderare om man tycker att designen och kodstrukturen är enklast möjliga. Om inte så fixar man till den, utan att ändra vad koden gör, refactor på engelska. Eftersom de tester man har, går igenom så är det tryggt att ändra implementationen.
Vi fortsätter sedan med ett nytt varv, test - implementation - refactor.
Enkelt så långt, men vad är poängen?
Vi börjar med poängen så att vi är överens om vad vi menar.
Testdriven utveckling (TDD) säger att man först skriver ett test som fallerar (viktigt), sedan implementerar man så att det inte längre fallerer.
I det läget tar man sig en funderare om man tycker att designen och kodstrukturen är enklast möjliga. Om inte så fixar man till den, utan att ändra vad koden gör, refactor på engelska. Eftersom de tester man har, går igenom så är det tryggt att ändra implementationen.
Vi fortsätter sedan med ett nytt varv, test - implementation - refactor.
Enkelt så långt, men vad är poängen?
Qualities Attributed to the Architecture
The System's Architecture Determines its Qualities
Functional requirements describe how a system delivers value. However, the quality attributes of those functions will make or break it. For example, if your functional requirment is about something that takes you from one city to another, I have a car to sell. Really cheap, for that matter.
Every system has an architecture. It may be elegant or it may be ugly. It may be described or it may be unknown. But it is.
Architecture is what determines the qualities that the system delivers. Is it fast? Is it secure? Can it be extended? Does it scale?
The qualities you strive for should determine the design of the architecture - not the other way around.
Every system has an architecture. It may be elegant or it may be ugly. It may be described or it may be unknown. But it is.
Architecture is what determines the qualities that the system delivers. Is it fast? Is it secure? Can it be extended? Does it scale?
The qualities you strive for should determine the design of the architecture - not the other way around.
Perspective of Retrospective
Don't skip the only meeting you can't skip
Scrum received some criticism today in Computer Sweden. The article featured an interview of Ken Schwaber and our guy Henrik Kniberg. Tobias Fors from Citerus was giving the comment that Scrum lacked support for retrospective. I am not sure if he was quoted correctly.
I am in the belief that Scrum has three roles, three artefacts and three meetings. Of the latter, there is one you should never skip.
Email eats your day
How your personal policy on email could look like
Email has reached into the everyday life of almost every profession. While I have been using it since the 80's, its usage has accelerated enough to make it an issue even to us who are used to it since long.
There is research that shows that we use a lot of time reading email. It may be waste.
Here is a suggested personal policy for handling you email.
There is research that shows that we use a lot of time reading email. It may be waste.
Here is a suggested personal policy for handling you email.
Usability will cost you money, ignore or score
As a product owner, I would like usability
Anna Forss writes under the subject "What do you test" some interesting and classical observations on how users cope with systems that has bad usability.
I will elaborate some on the comment I made at her blog.
As a product owner, you should be highly aware that usability will cost you money, regardless if you ignore it or not.
I will elaborate some on the comment I made at her blog.
As a product owner, you should be highly aware that usability will cost you money, regardless if you ignore it or not.
Wicket + Mockito = Love
Testdriven web development
I've survived my first Rocket Day. RD are our seminars at Crisp where we talk for half a day on a subject of choice. Mine was Test Driven Development with Wicket and Mockito.
I chosed to do a live coding performance as I liked to do a very down-to-earth, practical seminar.
The slides are currently in swedish but I will translat them to english. Later. ;-)
However, most of you read swedish so I have published them here.
I chosed to do a live coding performance as I liked to do a very down-to-earth, practical seminar.
The slides are currently in swedish but I will translat them to english. Later. ;-)
However, most of you read swedish so I have published them here.
Manage versions of your database schema!
Use a table to control which version database instances have
In software development where the system persists data in a relational database, it is important to keep track of changes to the versions of the schema.
The importance comes from that you always have several database instances to keep track of. There is the production database, the database for system tests, the database for acceptance test, the database for performance test, the database for development team and the database each developer has.
All these will be at different versions and aligned with different versions of the code.
The importance comes from that you always have several database instances to keep track of. There is the production database, the database for system tests, the database for acceptance test, the database for performance test, the database for development team and the database each developer has.
All these will be at different versions and aligned with different versions of the code.