Recently, I spent a significant part of the day in a meeting reviewing the year’s progress on several projects, including the introduction of an agile methodology — Scrum. The approach in the meeting was simple: write on a sticky note what we did well, and on another what we should not repeat or how we should improve. The subject was “Scrum/agile”. I only wrote one sticky note: “get rid of Scrum”.
Scrum, in my opinion, is (moderately) useful for small teams with a single, short-term project — something like a web application. The overhead it imposes vastly outweighs the benefits for larger teams and larger projects.
I am often asked by friends and acquaintances of various backgrounds, what I do for a living. Depending on my mood at the time, I can answer in any number of ways, but invariably my answers are met with blank stares, questions that clearly demonstrate that I have once again failed to make myself understood and an eventual change of subject.
This gallery contains 1 photo.
The Twitterverse has spoken, quietly, with a single vote — a cat it is…
This is another “HOWTO” post — setting up a Xubuntu-based kiosk, which I did to make a new “TV” for my kids.
In my previous post, I described technocracy as something that is positive in project and product management, and in team organization. In this post, to supply a boundary to my previous text, I will make the case for the opposite.
In a discussion with a “Product Owner” recently, I told him I take a more technocratic approach to project management than they did. We discussed different project management styles for the next hour or so.
I believe that
- to effectively and efficiently run a large team of developers who are collectively responsible for a product with a large code-base, that team needs to be organized as a network of smaller teams with experts leading each of those smaller teams, and
- to successfully manage an “agile” development team and create a viable product, one has to have a vision and break it down from there.
In this post, I show using a fictitious example why real-time systems are defined by their worst-case timing rather than their average-case timing.
Imagine you’re running a coffee shop — not the kind you find in Amsterdam, but one where they actually serve coffee. Your customers are generally in a hurry, so they just want to get a cup of coffee, pay and leave to catch their plane, train or automobile. To attract more customers and appeal to the Geek crowd, you name your coffee shop “Real-Time Thirsty” and promise an “Average case serving within one minute!”.
While you get many customers, you’re not getting the Geeks-in-a-hurry crowd you were expecting.
I used to have a server with five operating systems, running in VMs, merrily humming away compiling whatever I coded. I say “used to have” because I shut it down a few weeks ago. Now, I have those same operating systems, as well as a large number of others, running on systems I don’t need to worry about.
While writing about security — which takes a great deal of my time lately, which is one of the reasons I haven’t updated my blog as often as I usually would — I came to the conclusion that, while I recommend using STL algorithms, iterators and containers for safety purposes that doesn’t solve the problem when the standard algorithms don’t check the validity of their output ranges.