This years Smidig-conference is over, and I've had a week to digest the impressions. Overall it was a great experience. Lots of lightning talks, open space discussions and even some beer. My talk on Scrum and Technical Debt created some fuzz in the following open space discussion, so I guess it must have stroken s chord in some of the listeners :)
Janniche from Bekk challenged me on my claims, and frankly I think she may have a point. She argued that if tech debt seems to hide away in scrum, we are using scrum in the wrong manner. Technical debt should be up front, and thus decrease the focus factor. It requries developers to be honest and professional about their craftmanship. So maybe we should spend some hours on tutoring instad of repairing old defects ..
The presentation is unfortunately not available on video, but the slides can be found at http://www.slideshare.net/harals/scrum-skjuler-teknisk-gjeld-2277766
torsdag 29. oktober 2009
torsdag 1. oktober 2009
Time Snapper
I’ve been using TimeSnapper for a few days, and I’m definitively amused by it’s fancyness. Even though I’ve been present at work for perhaps 30 hours, it reveals that I’ve spent nearly a third of that time away from my workstation.
Moreover, it reveals that I spend most of my day inside if the www with opera. I haven’t been able to break that time slot down, but I’m afraid that most of my opera-time is devoted to issue tracking.
Moreover, it reveals that I spend most of my day inside if the www with opera. I haven’t been able to break that time slot down, but I’m afraid that most of my opera-time is devoted to issue tracking.
tirsdag 29. september 2009
Maven: updating you version tags
When you create another branch of your multimodule maven project, updating version tags all over the hierarchy can be a pain. You keep that snippet of code that does the job with 'find -iname pom.xml | xargs sed -e 's/4.0-SNAPSHOT/5.0-SNAPSHOT/g' .. and it works in most of the cases.
But there's another way: using the maven-versions-plugin. It allows you to change the pom version and parent version with a single target, e.g. mvn versions:set -DnewVersion=4.0b-SNAPSHOT.
Now, all of your maven modules in this project have been updated to the correct version, and their parent dependencies as well. Voilà :)
But there's another way: using the maven-versions-plugin. It allows you to change the pom version and parent version with a single target, e.g. mvn versions:set -DnewVersion=4.0b-SNAPSHOT.
Now, all of your maven modules in this project have been updated to the correct version, and their parent dependencies as well. Voilà :)
fredag 11. september 2009
Speeding up the development cycle at JavaZone
JavaZone 2009 has come to an end. It was a top notch conference: Great speakers and free beer.
My contribution was a lightning speed with entitled Speeding up the development cycle: Stash your files on a Solid State Drive
The abstract reads: Solid state drives have recently become easily available. Their performence may provide a way of reducing the time spent on on the development cycle: compiling, packeting and deploying applications. This paper shows promising results by locating the code base and local maven repository on a solid state drive. Initial experiments shows that time spent on waiting for your code to compile may be reduced by 50%.
You can get the slides at: http://www.slideshare.net/harals/ssd-dev
My contribution was a lightning speed with entitled Speeding up the development cycle: Stash your files on a Solid State Drive
The abstract reads: Solid state drives have recently become easily available. Their performence may provide a way of reducing the time spent on on the development cycle: compiling, packeting and deploying applications. This paper shows promising results by locating the code base and local maven repository on a solid state drive. Initial experiments shows that time spent on waiting for your code to compile may be reduced by 50%.
You can get the slides at: http://www.slideshare.net/harals/ssd-dev
mandag 17. august 2009
J2EE 6 på norsk
Jeg kom tilfeldigvis over denne engelske bloggen, som også kommer i internasjonalisert utgave: http://blog.taragana.com/index.php/archive/java-ee-6-highlights/no/
Og hva kan man si. Her er det flust av gullkorn. Skulle ønske Sun kom med en norsk utgave av Java EE 6.
The key features of Java EE 6
= Nøkkelen vise egenskaper av Java EE 6
RESTful web services
= Hvile web tjenestene
Annotations across Web API
= Merknader vannrett Web API
Mobile developers
= transportabel utviklerne
Scripting languages
= Skriften språkene
Manual editing of web.xml
= håndbok redigere bort av web.xml
Og andre mer anvendelige oversettelser:
Submit tips
= Underkaste seg drikkepenger
Albert Einstein
= Enskjønt Einstein
Og hva kan man si. Her er det flust av gullkorn. Skulle ønske Sun kom med en norsk utgave av Java EE 6.
The key features of Java EE 6
= Nøkkelen vise egenskaper av Java EE 6
RESTful web services
= Hvile web tjenestene
Annotations across Web API
= Merknader vannrett Web API
Mobile developers
= transportabel utviklerne
Scripting languages
= Skriften språkene
Manual editing of web.xml
= håndbok redigere bort av web.xml
Og andre mer anvendelige oversettelser:
Submit tips
= Underkaste seg drikkepenger
Albert Einstein
= Enskjønt Einstein
onsdag 12. august 2009
Blog blah blah
I just can't enought of them interesting blogs to read. And none of those publish exclusively interesting content. I find myself skimming titles to decide what posts to read.
So I got this idea: Combine Delicious and the blogsphere, and let me subscribe to tags or semantics or even something from a dewey-style categorisation of the world. Let me decide that I want all blog posts concering acquisitions of OSS companies by enterprise organisations. And let something, somewhere handle where to find those blogs, how to rate them, decide what to present to me.
Sort of like when people tweet about their blog postings.
So I got this idea: Combine Delicious and the blogsphere, and let me subscribe to tags or semantics or even something from a dewey-style categorisation of the world. Let me decide that I want all blog posts concering acquisitions of OSS companies by enterprise organisations. And let something, somewhere handle where to find those blogs, how to rate them, decide what to present to me.
Sort of like when people tweet about their blog postings.
tirsdag 11. august 2009
Spoils of Peopleware
So,
I read this black bible of technology workers satisfaction. Or perhaps programmers satisfaction. Or perhaps even skilled programmers satisfaction. It is said that this book should be kept secret from any management spy which happen to hoover over your desk. This because it is said to contain revolutionary ideas and truths about productivity, contrary to management theory and practice. So what is it all about?
Projects are failing to meet deadlines, to implement the specifications, to specify what the costumer really needs. The book claim that there are often no technological issues to explain this, but rather political and sosiological issues.
"Development is different from production". It's not a process that can be tuned and kept in a steady state, but instead a dynamic organism that should be nourished and kept happy. It's about creating value through ingenuity, not by running the motor at full throttle. One hour of overtime (at which you seldom can work at 100%) may cost an hour of undertime (where you recover and clean up after last nights desperate moves). Deadlines are not always absolute. Sometimes it's acceptable and even sensible to delay a deadline to fulfill quality requirements. I wish we could have both. "Quality is free, but only to those who are willing to pay heavily for it".
Then there's this part about the office environment. Cubicles and uniform environments are strongly discouraged. As opposed to factory workers, programmers are said to be intellect workers, and there are different rules that make them perform better. Cramped and noisy quarters can be a killer to productivity. Personalization enhances smartness. Interruptions steals a whole lot more of time than their duration, due to interruption of flow. You need at least 20 uninterrupted minutes to start working efficiently, and you need at least one hour to produce efficient results. Thus, behold of the E-factor: uninterrupted hours per working hours. Try measuring them by yourself. It's suggested that your will achieve a factor between 0.1 and 0.4. The number alone tells no story, but try to calculate it prior to and after a change, like moving to another office space, tearing down the office walls, putting up walls, switching offices and so on.
The right people is another keyword. A short formula for success: get the right people, make them happy so they won't leave, turn them loose.
The first clause is about hiring. Have an audition. Make the candidated program. Accept those that your collegues think highly of. Measure the cost of turnover. It can easily be as much as 5 months of lost work. Consider them people instead of workers. Most people leave because 1) they're just passing by, 2) they are feeling disposable or 3) they are not loyal because they are being threated as workers.
It's all about putting a kick-ass team together. There's this concept called jelling, which is rather difficult to quantify. It happens when people are professionally happy with each other, they feel identity and ownership and eliteness. Don't change a winning team. Spend some money on jelling acitivties, like teambuilding. A few hundred hours can easily be spent, or what?
So, this was a quick and superficial summary of the epic. Mostly written down to serve as my own mindmap for remembering things. Everything favors the developer, and I guess any manager would have loads of counter arguments to any of the claims. I agree with the majority of claims, and then I guess the rest is not applicable to my situation. It seems as if the paradise of developers is a small company owned by the developers themselves. Growth implies overhead, and the overhead eats up the advantage.
But then there's some advantages of working in a production environment as well. Your schedule is predictable. Your hours are predictable.
Your duties are predictable. Your requred skills are predictable. And then sometimes they're not, but then it's no longer a stable and optimised production process, is it?
I read this black bible of technology workers satisfaction. Or perhaps programmers satisfaction. Or perhaps even skilled programmers satisfaction. It is said that this book should be kept secret from any management spy which happen to hoover over your desk. This because it is said to contain revolutionary ideas and truths about productivity, contrary to management theory and practice. So what is it all about?
Projects are failing to meet deadlines, to implement the specifications, to specify what the costumer really needs. The book claim that there are often no technological issues to explain this, but rather political and sosiological issues.
"Development is different from production". It's not a process that can be tuned and kept in a steady state, but instead a dynamic organism that should be nourished and kept happy. It's about creating value through ingenuity, not by running the motor at full throttle. One hour of overtime (at which you seldom can work at 100%) may cost an hour of undertime (where you recover and clean up after last nights desperate moves). Deadlines are not always absolute. Sometimes it's acceptable and even sensible to delay a deadline to fulfill quality requirements. I wish we could have both. "Quality is free, but only to those who are willing to pay heavily for it".
Then there's this part about the office environment. Cubicles and uniform environments are strongly discouraged. As opposed to factory workers, programmers are said to be intellect workers, and there are different rules that make them perform better. Cramped and noisy quarters can be a killer to productivity. Personalization enhances smartness. Interruptions steals a whole lot more of time than their duration, due to interruption of flow. You need at least 20 uninterrupted minutes to start working efficiently, and you need at least one hour to produce efficient results. Thus, behold of the E-factor: uninterrupted hours per working hours. Try measuring them by yourself. It's suggested that your will achieve a factor between 0.1 and 0.4. The number alone tells no story, but try to calculate it prior to and after a change, like moving to another office space, tearing down the office walls, putting up walls, switching offices and so on.
The right people is another keyword. A short formula for success: get the right people, make them happy so they won't leave, turn them loose.
The first clause is about hiring. Have an audition. Make the candidated program. Accept those that your collegues think highly of. Measure the cost of turnover. It can easily be as much as 5 months of lost work. Consider them people instead of workers. Most people leave because 1) they're just passing by, 2) they are feeling disposable or 3) they are not loyal because they are being threated as workers.
It's all about putting a kick-ass team together. There's this concept called jelling, which is rather difficult to quantify. It happens when people are professionally happy with each other, they feel identity and ownership and eliteness. Don't change a winning team. Spend some money on jelling acitivties, like teambuilding. A few hundred hours can easily be spent, or what?
So, this was a quick and superficial summary of the epic. Mostly written down to serve as my own mindmap for remembering things. Everything favors the developer, and I guess any manager would have loads of counter arguments to any of the claims. I agree with the majority of claims, and then I guess the rest is not applicable to my situation. It seems as if the paradise of developers is a small company owned by the developers themselves. Growth implies overhead, and the overhead eats up the advantage.
But then there's some advantages of working in a production environment as well. Your schedule is predictable. Your hours are predictable.
Your duties are predictable. Your requred skills are predictable. And then sometimes they're not, but then it's no longer a stable and optimised production process, is it?
Abonner på:
Innlegg (Atom)