A Start-up Life
I decided to change the title of the week’s highlights to reflect the most interesting topic I discovered running through my feeds. The same title every time is just boring and gives the impression there is no content inside.
The 1st prize this week goes to Jake Scruggs’s “On Going Fast Because You’re A Start-up” blog post. Jake talks about a typical start-up frustration experience. The “experiment” phase should not be longer than 4-6 months and after that the entrepreneur should know if it’s worthwhile. From the technical standpoint that should be also the time to plan based on the user feedback. The problem is that once lower quality is established and there is a public release it’s too late to educate the customer about the need for quality. So my suggestion is never trade quality for speed, it’s a false impression of speed. Yes the entrepreneur will probably go finding someone else for a 4th of the price but we (the craftsmen) have the responsibility to tell the customer what to expect. And this post is a good example to tell other people.
Other topics this week
Extreme Enthusiasm Blog Archive Not wishful thinking… I want to remember the example of the toddler baby. They are not sold the idea of walking on two feet and still they are able to move quite well anyway on four. They try the new “practice” anyway and they see they can cover much more distance with ease. So, yes, you don’t need to try anything new if you are successful already. But you might discover you can do the same thing with less effort and spend the energy for something else.
Ruby Functional-style Pattern Matching, Using the Case Gem - Dean Wampler… Interesting use of pattern matching instead of explicit conditional to control the program flow. The best would be to have a method definition in Ruby that accept a “Case” pattern declaration. When the method with that name is called the selection of which overridden version is done by the patter matching. Should we fork a functional Ruby? :)
Pair programming with multiple mouse pointers and keyboard… Wondering why I never thought about this before :) Why a screen should be constrained to just a single user interacting with it? Multiple mice and keyboards can be connected to a single screen with the use of a special switch and used sequentially. But the possibility of having multiple mouse pointers and users sitting in front of the same screen offers new possibility for pair programming. For a little more on discipline, you cut down on all those “can I grab it for a moment” synchronization points! Thanks to Josh for pointing this out.
Agile: In A Flash: Extreme Measures… This is a series of flash cards collecting agile and programming principles. The format is a pleasure to read: small enough to attract your attention with a single catch sentence. I link to this one in particular (but go and read the rest) because it’s full of original and advanced tips. In particular I like the technique of splitting a team so that developers aren’t tempted to cheat on the done percentage of a story and sneak features into the following iteration. Since they can be in a different sub-team, there is no next iteration to close the user story. The other interesting tip is to discard work which is over 3 weeks old. I would also add to clean-up the task list of stale/old tasks that never get done in the hope to have more time in the future. I know from experience that they never get done.
Jim Weirich - Threads - RubyConf 2008… Classic threads presentation but as usual with Jim Weirich entertaining and fun. Common aspects of concurrent programming in Ruby are covered here and was a good refresh for my Java memories too. The problem with thread is all about shared state and very similar to transaction management at the end. You need to make atomic a sequence of operations with something like a Mutex. Deadlock is when all the thread are in a wait state (and this happens when a couple of them are waiting for each other) and can be solved with prioritization. Suggestion: if your application is highly concurrent in nature, consider to use a secondary inherently thread safe language like Erlang or Clojure instead of trying to use thread controlling constructs of the sequential language.
2 years ago