The idea of variable prefixes
The idea of prefixes on variable is “very” old. They are used to tell the developer what kind of variable he is using. The first prefix for example is m_ and the conclusion is this variable is a member. When I learned programming we had to give the developer more information in case of a member. Like the type of it like an integer became m_i. Continue reading
This is a presentation I hold in 2010 for bbv Software Services AG. It shows how my team lives Scrum.
I’d be glad to see your feedback in the comments section…
This is the slide deck of my LAS 2010 presentation: From user stories to architecture.
We use a lot of open source libraries and components in our daily business. Open source libraries provide us a big advantage regarding time to market with our products. Every time when we are facing a problem in our software (problem is related to business domain to implementation domain difficulties) we first look into the open source world if someone has already solved that problem or even parts of it. Sourceforge, codeplex and google code (to name a few) are often the first pages we visit to look for code samples, libraries and frameworks. But how can we find the needle in the haystack?
This is the slide deck of a presentation I gave for bbv Software Services AG at two events in 2009 along with some comments .
If you are interested in seeing this presentation live (either in German or English) then please contact me.
In an agile project, the architecture has to evolve together with the requirements and the code. In this presentation, I’ll show you our agile architecture lifecycle.
Living and breathing Scrum means for a team being self organized. My experience in different Scrum projects tells me that this is not always an easy task to grasp. Experienced Agile teams are self organized when it comes to maintain the code base or gathering information for user stories from the product owner. But what happens when soft skills are involved?
When I talk with fellow developers new to Scrum, I often hear a fundamental misunderstanding about Sprints. These colleagues are normally used to Waterfall or RUP methodologies. As a consequence, they think of Sprints as very short repetitions of the following phases: requirements (planning meeting), design, implementation, test (sprint review as acceptance).
And this is completely wrong!
Let me tell you why.
How to find a concurrency bug – this was the question I asked myself some time ago.
It is always very hard to find a concurrency bug. Mostly you have no idea when it happens or if it is really a concurrency issue or some nasty bit of code. If it is a concurrency issue the question is if the bug is in your code or in a supplied library? Will the problem happen only on multicore processors or on any machine? Besides the technical problem the customer is eager to get a solution and management… we’ll i guess you know the story.
I won’t be able to tell you everything there is to know about concurrency testing – but I’ll show you a way that worked for me in most cases.
Important announcement for all those certified scrum masters out there. The scrum alliance recently changed their policy of the certification process for the certified scrum master. Thanks to Ken Schwaber taking the exam and therefore prove that the individual was able to memorize the scrum basics on a theoretical basis is now more important than the experience of living and breathing scrum…
Effective 1 October 2009, certifications will be valid for two years from the date when the CSM passes his or her certification exam. If an individual takes a CSM course after 30 September 2009, he or she will have ninety days after the course date to pass the certification exam.
If an individual earned his or her certification prior to 1 April 2009, the individual must take the initial online certification exam by 1 April 2011 to maintain certification.
If an individual earned his or her certification between 1 April 2009 and 1 October 2009, the individual will have two years from the course date to pass the CSM exam and maintain certification.
Additional information can be found on Peter’s Scrum Breakfast blog
Recently, I was asked by a colleague why I like Scrum. I didn’t have a good answer at hand immediately, and since then the question bugged me. Therefore it’s time to give you my top ten now:
- Team Spirit
- Continuum Of Work Pressure
- Don’t Assume, Show
- Team Knowledge Over Experts
- Control Is Good, Presentation Is Better
- Continuous Improvement
- True Incremental Development
- No One-Man Shows
- ROI Is The King