Reblog

Agile 2009 Report

Finally I managed to attend the biggest of the agile conferences around. Unfortunately I missed the first 2 days which means 50% of the conference. For the 2 full days I was there I had the pleasure to attend interesting talks, knowing smart people and get a sense of how agile is doing these days. The organization was almost perfect, excluding the confusing aspect of “stages” as categorization for talks. But that’s a minor problem in my opinion. Please jump right at the bottom if you only care about the conclusions.

The first talk I attended was almost by accident considering the complete lack of time I had to go through the program and decide carefully what to see. So the criteria was: choose a title that sounds like new stuff, at least you’ll learn something different. With that in mind I attended “Stepping Up and Stepping Back: the Leadership tipping point” by Pollyanna Pixton. Project leadership talks are not usually on my radar, but I knew Pollyanna by fame. The talk was centered around the idea that today’s style of leadership should be less intrusive as possible to foster team creativity. This is also the topic of the last book of Pollyanna. The exact opposite is the command-control kind of leadership, the one where is the leader who takes ownership of actions instead of letting the team assume the control. The leader should step back even when they know exactly the solution for a problem and let the team learn from mistakes. Apparently leaders appear to do nothing while instead they prepare the team to take responsibility. Not imposing doesn’t mean not to lead. We even practiced how not to answer questions!

Then it was my turn to speak. I think You Say Tomato I Say Pomodoro talk went great. I worried that speaking for 90 minutes was too long, but when you put practice into the mix, finishing earlier is never an issue. I had around 15 people attending which is not a lot considering the size of the conference. Feedback was great, averaging 4 to 5 stars. Probably people already got their Pomodoro talk the day before and they were not interested in another one. I think my title was misleading in this sense, it sounded more like an introduction and it was not. Also: Neal Ford was talking about emergent design in the other room and that didn’t helped a lot :) I’d like to extend the talk to a 3 hours session in which instead of driving the exercises I give them to the public with my supervision.

I then moved on the other building where the Software Craftsmanship North America was taking place. I attended Ward Cunningham’s talk about “bacteria oriented programming”. Don’t be fooled by the apparent non-sense biology, electronics and programming mix of this “old guy” of the agile community. There is an important take away: never stop to a single discipline, move around, let the side thinking permeate your daily programming. He gave us an example of a “fuzzy” protocol called Bynase, where instead of defining a communication protocol, a continuous stream of impulses is used between computers and sometimes the pulse is accepted and sometimes it’s not. This resembles cellular communication where the cell transmission triggers communication between other cells. You can find more here. The line up of speakers for SCNA was impressive but I decided to go back to Agile 2009. That was an hard decision though!

I needed some rest, but I was just in time to hear the remote pairing experience report by Tim Ottinger and Tim Gifford. I was already following Tim’s effort from his blog while doing a similar experience in parallel with my team. Conclusions are the same: no silver bullet but just a mash-up of tools to use to fail-over when connection isn’t perfect. And it’s never perfect. You also need to think about a specific “remotiquette” and learn what you can and what you can’t do at the phone/screen. Mostly common sense I’d say. I agree with their conclusion that we are still lacking a complete solution for remote working even if features should be clear by now. C’mon vendors!

I then participated to my first Agile Jam Session. I’m talking about a real jazz jam session at the Muzic Masti stage where we self-organized to create the band: yours truly at the piano, Chris McMahon at the bass, Paul Rayner at the guitar and Henrik Kniberg at the drums (he was the pianist but he kindly accepted to let me play). We’ve got several other instruments coming and go and unfortunately I don’t remember the names. I stopped only 2 hours later to move to the DWR party at the Elephant Castle with Paul. We were able to stay only 1 hour because after a while we couldn’t hear each other or anyone else because of the confusion. Anyway, great night.

First talk I attended on Thursday was Styles of TDD: First tests by Naresh Jain and Michael Feathers. This was a practice session on TDD with an exercise based on a billing system application to develop. I abandoned after the first break. I couldn’t understand what the goal of the session was. I had the impression we had to develop test first a few features and then discuss what went good or bad, but I’m not sure. If that was the goal, it was too much basic stuff for me. I expected to learn different styles of TDD (whatever that means, that was my curiosity) but it was just an introductory session with people discussing why you should or shouldn’t test a specific feature.

It was then the time of Metrics in an Agile World by Rob Myers and James Shore. After an interesting start about the meaning of “measure” for common life things like the grade for an egg or what is exactly a “good tomato”, I got lost in the pictures. I think I’m becoming very impatient (which is not always good) so maybe this time I was too quick in judging the talk. But I started feeling frustrated when: I realized the pictures were too invasive and when James Shore asked the audience to organize into groups to brainstorm a few ideas about metrics. It’s true: sometimes the best talk is the one where you don’t receive answers but where the attendees collectively found solutions. But in this case I was looking at pretty pictures on the screen and listening to curiosities about grading eggs and then asked to find a definition for metrics. I was not ready to workshop at the table because I couldn’t understand the goal. As I said, I was too quick. I should have done the exercise and stayed a little more. The critique for the presenter is: pretty pictures are fine until it’s evident that they are just used to catch the attention.

I closed the morning with some bureaucracy at the speaker booth and then lunch. For the afternoon, frustrated by the lack of pragmatism of the previous talks, I selected something very practical and Ruby-ish like Acceptance testing Java Applications with Cucumber, rspec, and Jruby by Dean Wampler and Aslak Hellesøy. I was curious to be taught by Aslak about something I knew like cucumber, but not in all the details. It went pretty well, I learned a few things about cucumber I never used and also how to use in cross-language environments. I also got a chance to go back to my Java days and remembering how to program in Java. Man, that was so quick! All those years are still there. Anyway, I had to left before only because there was a talk I wanted absolutely to see.

The last talk for Thursday was Slow and Brittle: replacing End-to-End testing by Arlo Belshee and James Shore. I went there because I think Arlo is a genius and also because I appreciate James’ writing on his blog. It turned out to be a little different from my expectations, but overall a great session. In this case, the fact that the audience was required to work on a problem was clear since the beginning. That’s ok, no pictures, not even slides. Trust engaged. The problem of end-to-end testing is the problem of maintaining and executing acceptances, integration or any other kind of test where the components involved are loosely connected. We decided to name these end-to-end. Now, execution and maintenance of end2end tests is notoriously such a big pain that many teams decide to remove or to do a light use of them. Given the fact that you can’t sell the customer buggy applications, in which way we can replace end2end testing? There was no definitive answer but a list of common alleviators such as good mocking, just the right amount of exploratory testing and even a language tailored explicitly for end 2 end testing. Arlo’s approach is probably the most interesting: they delete end2end tests when the feature is stable and necessary unit tests are in place. I proposed a Pareto-like solution: let’s instrument the application so that the most common usage paths are recorded. Knowing that those usage paths cover the 80% of the application business value, let’s use end2end to cover them and something else for the rest. I was not able to explain my idea to the table, so we opted for a better use of plugin oriented architectures based on the facade pattern. I enjoyed the conversation and the challenge. Impressive was to see James driving the room full of people and the lighting talks.

This is basically the end of my first Agile conference. But probably the best talk of the entire week went on during the banquet. I had the pleasure to see Jared Spool in action with a talk about the importance of user experience design. A great build-up of anecdotes and facts to sustain the thesis that user interface design is the most important aspect of software development. Totally agree and you have to be good at it. He’s just a great speaker, you have to watch it to understand. Some interesting take away: there must be a vision for the product and everyone in the company should endorse it. Good design cannot always be explained completely: you need to learn from the masters and then reproduce in some sort of unconscious way. And many many more. I think this presentation and probably a few others should be online on www.InfoQ.com any time soon.

I had a great time. Too bad I was not there from the beginning and I was too busy the days before. My planning certainly suffered from my poor conference preparation. I also met wonderful people that is probably the most important part. As I heard from others the last year, attending this conference gives the impression Agile crossed the chasm. My impression is more that Agile stalled right before crossing the chasm. Many know about Agile but they are still early adopters and it looks like there will be no more innovation from now on to increase the interest. The Agile 2003 program, for example, isn’t very different from this year program except for the quantity of sessions: after 6 years TDD should be considered as a complete obsolete topic, but we are still here struggling with it.

Not Reinventing The Wheel?

It depends.

Have you ever been asked to not “reinvent the wheel” by a customer or maybe your boss to implement some functionality for an existing project? It’s a pretty common situation I think. Extension by reuse is a nice thing to have and all well crafted projects with low technical debt are ready to be improved without the need of “reinventing”. But what exactly the boss is asking to the team? The boss is probably just afraid of the team writing the same code twice, without copy pasting (!). If you’re lucky maybe your boss is smart enough to imply “writing the same code twice instead of reusing already existing components”. Anyway, the final goal for the boss is to reduce developing time as much as possible without you wasting time re-thinking something that is already built in the application.

The problem is that to know if you can reuse effectively, you need to know the code-base. If the methods are 100 lines long with high cyclomatic complexity values, chances are that they are very tied to specific use cases and the business logic is scattered across the sources without the necessary modularization. Let’s say you agree to work on this project by just re-using the existing classes and hoping everything will be smooth and easy. The reality is that to avoid to reinvent that wheel you’re now forced to add even more conditionals, follow convoluted paths and potentially breaking other use cases (especially for low test coverages).

What happened? The new feature could potentially take twice as necessary to pay for those wheels that were not reinvented. Second: the wheels are now more tangled than before and exponentially more complicated. The solution is not of course to re-write the code (even though you might be forced to if the situation is desperate) but to apply the legacy code workflow (cover with tests, extract logic, refactor). If your boss fails to understand that the price to not reinvent the wheel is way higher than extending well crafted software, then the project is doomed. This seems often the case for startups with the need to monetize as fast as possible and sell the mess right after. By the way, why do you think your car repair shop wants to call you back to give you an estimate about the damage of you car before moving forward?

Let’s say you explain the danger of accumulating technical debt to your boss. You shouldn’t be tempted to consider copy-pasting a faster alternative to deal with the mess. Reuse by copy-pasting is possibly more exponentially dangerous than spreading conditionals across the code. It’s just a matter of days that you’ll find your self fixing the previous use case forgetting about the copy-pasted-changed added functionality. Seriously bad idea.

Conclusions

So the next time you’re asked to not reinvent the wheel, instead of blindingly accept on the spot because you totally agree, you have to know what the current state of the code is and only after that you can give an informed answer and a meaningful estimate.

Embedding MacRuby

The actual implementation of MacRuby contains a facility method used by HotCocoa macrake tasks and by the embed MacRuby target in XCode. The method only change the executable to point to the embedded MacRuby in the .app file. But all bundles in MacRuby contain a reference to the system MacRuby installed in /Library/Framework, not the embedded version. This prevents the distribution of a MacRuby application to computers without a system-wide MacRuby install.

Waiting for the next MacRuby release where this problem should be fixed, an easy fix is to run install_name_tool on all the bundles in the directory. From the command line:

    1 mkdir ~/tmp
    2 cd tmp
    3 hotcocoa embedded
    4 cd embedded
    5 macrake deploy
    6 LIB=MacRuby.framework/Versions/Current/usr/lib/libmacruby.dylib
    7 
    8 find Embedded.app/Contents -name "*.bundle" \
    9 -exec install_name_tool -change /Library/Frameworks/$LIB \
   10 @executable_path/../Frameworks/$LIB {} \;
   11 

Sorry for the poor line wrapping to make it readable. You can check the results with:

The first lines are needed just to setup a HotCocoa example project. On line 8 I’m applying install_name_tool to all bundles in the distribution. The same can be done to a MacRuby XCode project created with an Embedded target.

If your project is HotCocoa based, you can add the following macrake task to the Rakefile in the root directory:

As you can see I’m also removing unnecessary files for a MacRuby 0.4 distribution to shrink the application size down to around 15Mb. Not too bad considering an entire Ruby runtime (MacRuby) is included.

Life Lesson From CouchDB

Another Friday! Time to dump the selection of links that yours truly collected on the interweb in the past weeks. I had to wait a bit to accumulate enough material worth publishing. As usual the description is a mix of quotes and personal opinions about people, things and facts. I also try to elect a “most interesting of the week” and this time I had an hard work. I was struck by the life lesson coming from the development of CouchDB. I didn’t know anything about Damien Katz and this presentation by InfoQ is one of those you see once or twice a year. Damien was laid off, he had to move to a cheaper place and start all over with two growing kids. How do you find the motivation to grow your own idea and live on savings while nobody cares about you and your work is the main topic of the talk. This is how CouchDB got started. Damien also talks about choosing Erlang and JSON over HTTP and some more technical aspects. Simple and regenerating talk.

Newspeak and Pluggable Types with Gilad Bracha - Software Engineering Radio… Here’s the best analogy so far comparing static type system VS dynamically typed system. In a static type system applies something similar to the “presumption of guilt” from the Napoleonic Law: the compiler stops the program (guilty) if the program doesn’t comply to the type system even if it makes perfectly sense at runtime. The compiler can’t prove the program is “innocent”, so it has to be wrong! In dynamically type systems the program is allowed to run and judged only after the facts. Statically typed languages are therefore more restrictive but this doesn’t imply they are more “secure”. Second: the type system is similar to a BDUF (big design upfront) and restricts the possible uses of the language to what it was designed for: have you tried AOP in Java and then in Ruby? Dynamic languages accommodate “side” uses more easily. The rest of the podcast is centered around the features of NewsSpeak, an interesting language that deserves attention.

InfoQ: Jazzers and Programmers… This is mostly about jazz than programming. But I appreciated the concise history of my favorite music with examples, quotes from great musicians and a little theory. I’d certainly point someone to this presentation to have a quick introduction to Jazz. There is a clear parallel between Jazz and programming. Something common is the need for continuous practice in both. We call this “software craftsmanship” and apparently developers of our times don’t practice often enough. I also think that there is less room for improvisation in programming than Jazz. Most of the time in programming you have to follow rigid rules (like classical music) and the real improvisation is when a tool or technology is used in a different and unexpected context, like for example Erlang for mutli-core CPUs.

How Productive Was the LetMeGo Immersion? «  Alexander’s Blog – The Making of LetMeGo… From one side I can only admire what a small team was able to accomplish. From the other I can’t stop thinking that this project is seriously screwed. Just the fact that you’re forced to a 90 days 24/7 with something like 12 hours working day to produce a partial beta smells bad. I understand how this can be a wonderful experience. But I suspect they accumulated an huge pile of technical debt. If I were an investor I wouldn’t invest in LetMeGo because it seems like a bomb ready to explode right after a few months of exercise. I could be wrong of course, or just envy because when you have a family you’re done with this kind of things. All the best to the project, we’ll see.

Hanselminutes Podcast 171 - The Return of Uncle Bob… This time Uncle Bob talks about professionalism. IT industry is amateurish to some extents and lacks the same level of professionalism of other professions. Rituals can be a measure of professionalism, since they are the result of a consolidated discipline. Of course you try not to abuse rituals and loose the intent behind the discipline (like completely skip design to jump right into testing, see Jim Coplien). After talking about the need for architects to also be developers to feel the pain they are asking for, Uncle Bob also speaks about the density of a language, intended as the concentration of meaning for a single word or even a single character. See the nice Game of Life in APL screencast that illustrates the concept here: http://www.youtube.com/watch?v=a9xAKttWgP4. I especially like this quote from Uncle Bob: “I want them to find me with my nose stuck between the keys of the keyboard”. Yeah, code code code.

Hanselminutes Podcast 169 - The Art of Unit Testing with Roy Osherove… An interesting podcast again from Hanselminutes. And again about unit testing. Here’s some take away: if you have tear-downs in your tests those are probably integration tests. If you have class based setup tear-down again those are probably integration tests. If you do a lot of corner cases testing around a method, you’re probably doing after-the-fact testing. A good definition of mock object: if you’re setting expectations on an object which is not part of the project, that object is a mock. You don’t make assertion against a stub for example. When do you stop testing? When you’re comfortable with it, that is, when all the ideas about how the software should behave have been implemented. And of course you should stop at the most interesting cases without over-specifying.

Push Notification & Store Kit - An Interview With Urban Airship… Here’s an interesting discussion that explains the technical details of two new capabilities of the iphone sdk 3. Push notification is a stay resident application running on the iphone capable of receiving messages and dispatch them to other applications. There is a server side notification service involved with persistent queues maintained by Apple. The Push Notification removes the need for an app to poll a server remotely dragging the batteries out using a persistent IP connection. The store kit is an API that allows iphone apps to present mini-stores to their users to buy additional capabilities. Interestingly enough, there are companies like Urban Airship producing intermediate layers (or a server with an application on top of it) because the whole process requires good programming and administration skills. Kudos to Dan Grisby for the very good questions.

The Short Term Cycle of Productivity

I’m sure I’m not saying anything new that psychology doesn’t explain already. Anyway you may find some answers here.

The Short Term Cycle

When exposed continuously to the same subject (idea, abstraction, project, whatever), even for a few hours a day, the brain creates a short term memory of the content of that subject. The frequency determines the freshness of the content and consequently our capability to create higher abstractions and side thinking on that subject. I suppose you realized at least once that after a long period of intense concentration on a problem it’s now harder to get distracted at the point of having trouble to sleep. I call this short term cycle of thinking, where an idea can be analyzed and exploited easily with negligible effort.

Productivity

Productivity happens when the short term cycle is established and the brain is ready to build knowledge on the subject with ease. Needless to say, the key to be productive is to maintain the short term cycle alive by establishing a daily (or a cyclic) refresh. At productivity peak the refresh can as short as 1 hour/day (depending on the kind of project of course). For software developers an example of daily refresh can be fixing a bug on a project. 1 hour to fix a bug is enough to keep the project alive in the brain without a tangible effort to context switch. For a piano player half an hour of scales are enough. For a runner, 3 miles 3-4 times a week. Of course it depends on your goals. In general, the popular “daily practice” is what creates the virtuoso cycle.

Feedback

Motivation depends on feedback. More specifically good feedback. When the results of some intense work is positive and rewarding motivation increases. When results are absent or bad, motivation decreases. The feedback can be as “stupid” as a number that goes up or down, a changing color, or some modifications of the physical world that can be seen and measurable. But what’s good or bad isn’t always the important factor. Motivation stays up when accepting a challenge for a partial failure. So the important thing is to find a feedback no matter what or how. The more visible and clear the feedback is, the more the motivation is affected.

Distractions

Unexpected, continuous and random distractions destroy the short term cycle. Good and planned distraction are healthy and welcome. The reason is easy: if the distraction is planned and cyclic it just creates the perfect spot for a managed break of the brain. Do you remember what happens when you move to a new apartment? Several unexpected things can happen: the DSL doesn’t work, the fan makes too much noise, there are all the boxes to unpack and so on. This is random distraction that brings the short term cycle to its knees. Focusing on goals becomes difficult, feedbacks are too often negative, motivation goes down if you don’t pay attention. This can result in a vicious cycle, exactly the opposite of the virtuoso cycle of productivity.

Frustration

The problem is that is not always possible to identify when the distraction pattern is about to change to become random and unplanned. When that happens it usually generates frustration, a condition where the problem cannot be fixed and there is apparently no solution for some long period time. It’s also easy to blame some unfortunate “bad shape” when frustration occurs because the cause of the problem is not known. Of course there is a real “bad shape” but if you are an healthy person with just a few colds a year, is pretty much possible that your frustration is not generated by physical conditions.

Self-check

If you feel frustrated ask yourself the following questions:

• Is the short term cycle holding? Are you dedicating consistent and repeatable time to your goals?
• Are feedbacks in place? What “numbers” change by working on the goal?
• Do you find yourself wandering around for a reason you don’t recall? Like I went to the bathroom then I met a colleague, then I went for a coffee, then I don’t remember?
• Do you see a change in the pattern of distractions? Several unexpected interruptions several times a day for a few days for example.
• Are there objective reasons to think that you have some kind of sickness determined by external causes? This is usually something a doctor can confirm.

Based on the answer you can understand if what you are experiencing is a fracture of the short term cycle determined by external unexpected distractions that you didn’t recognize as such.

Taliban Mode

There is no easy solution here. The only solution is temporary deprivation. You need to accept to remove several useful habits and pleasures. Temporarily! For how long it depends but usually weeks. The deprivation is necessary to re-establish the short term cycle and consists of removing useless and useful distractions for a while. Total immersion so to speak. Feedbacks in place are a must. How to find or create feedbacks is a subject for another post. I found mine with the Pomodoro Technique. Taliban Mode is how I call the fundamentalist approach to re-establish the virtuoso short term cycle. When it is back, restrictions can be gradually relaxed. Below an example of a taliban mode:

Uploaded with plasq’s Skitch!

What is on the Taliban Mode is very personal. At the beginning it can be more restrictive, for example by limiting (not removing) hobbies and extra-work activities such as sport. The key is to remember that this is just temporary and the result of the effort will be visible only after a few days and more importantly, this is the key to re-establish the short term cycle of productivity. Hope you found this article useful. Let me know how in the comments if you want.

Back From The Diet

The Good

• Cutting the long tail: the diet had the interesting side effect of cutting the long tail of information. The long segment of the tail includes very specific and localized news: the more specific the information the less subscribers following that source. The diet moved the “interestingness trigger” higher in the curve by eliminating too detailed source of information. Only the fittest news will survive the long tail and move up (the fit function here is the general consensus that the news requires attention). Since there is a not-negligible traveling time for the news to move up, with the diet I’m trading freshness of information for quality by being not informed as soon as the information is created.
• Push vs Pull: the diet eliminates all sources of “push” type of information. If something is sent to you and collected inside an inbox that’s what I call “push”. It can be counter-intuitive: you might think that if there is a subscription then the model is “pull”. True, but the inversion happens when I start polling the subscription to see if there are new items transforming the good push into the evil pull. The bad of course is if you check constantly.
• Presence amplification: I don’t remember where I read it, but for each email sent a few more will be sent back to you. It’s not different for other kind of web presences: Twitter, Facebook and a whole bunch of other services offer you the possibility to say something. Don’t get me wrong, that’s great, but when too many feedbacks accumulate you need to allocate time to digest the list.

The Bad

• Missing relevant news: of course this is the main reason to stay in the loop. Aggregators like InfoQ (and many others) are at the top of the long tail of information and produce more digested information (for example by summarizing interesting posts from mailing lists) than Twitter for example. But I still missed some relevant information (to me) that didn’t make it to the general aggregator. Expected: this is the trade-off I was talking about.
• In the loop: another important aspect of micro-blogging is the way it reports about other people doing stuff. Staying in the loop boosts motivation because it re-creates a working environment where other people are doing what you’re doing. Twitter is much more powerful in this context than blogs or x-casts. This is especially true if you work alone from home without a physical team.
• More time available? If you remember one of the reason I started the diet was to spend more time reading books. I thought the time not spent reading online could easily be replaced by books. It only partially happened. I need at least the time to read a chapter at once because for smaller fragments I easily get lost trying to remember what that sentence was about. So yes, more time available but in very short segments not suitable for reading a book. For this specific problem I prefer to allocate a couple of hours here and there.

So I enjoyed in the last two months the possibility to make a comparison between too much and fragmented information and no information at all, or close to that. Trevor was right! :) I need to reduce information consumption or stay away for a while when I’m wasting too much energy. In the last 2 months I learned how to trim information to the essential and how to live without it. Now I can gradually increase the flow back and enjoy staying in the loop. This is especially true these days working alone on projects: the presence of a virtual office with virtual colleagues helps me stay in focus and solve problems. Let’s see.

Programming Languages

This time I want to dedicate the opening of the last 2 weeks’ highlights to programming languages in general. Why? Because I had a chance to attend the Chicago Chapter of the ACM presentation with Ola Bini on Ioke. Programming languages are a business domain exactly like banking or insurance with the difference that the “business analysts” is a programmer by definition. For some reason I didn’t pay too much attention in the past to this business domain and I was wrong. Shame on me. I came to the conclusion that learning about compilers, optimizations, expressivity, AST, interpretation and so on is vital to the life of a programmer. Of course you don’t need to be able to create your own language, but you should know what we are talking about. Back to the presentation: I think Ola was giving his best. Of course Ioke is Ola’s little kid, who wouldn’t be thrilled to talk about it? Sure enough the talk is about the language, but there are interesting cross-language considerations. I realized how specific is the domain of languages, it really requires you to be into it to understand everything. For this reason, Ioke is a good teaching language because it’s all about language theory than for example, performances or concurrency. Final note: stating that all other languages are crap is not fair, even from the point of view of expressiveness which is subjective matter. If expressiveness of a language is the deviation from the idea you have in mind and what actually can be coded, then also Ioke is crap to someone who of doesn’t think the same as Ola.

Other interesting topics includes:

The Java Posse - Staffing Agile Teams… Interesting panel. I think Barry Hawkins is the chair master (http://www.yepthatsme.com/) and he’s the one saying the most interesting things. Overall the talk illustrates different personality types for agile programmers and what to search for to staff agile teams. Sometimes is necessary to turn down awesome skilled people if they don’t fit into the team. For example ability to cooperate must be just the right level: humility is important as well as not over-cooperate (questioning too much about team choices instead of having things done). Prefer people you need to bring up to speed in 3/4 weeks instead of skilled people that you can’t unlearn if they are assholes. Inefficiencies of the interviewing process can be exploited by contracting to hire. Problems are a certain kind of super-stars: they give the illusion f productivity creating unnecessary complexity that they only can understand. Sometimes you just need some more courage to let go people that are not a good fit.

Ari Zilka on Terracotta’s VMware integration… Again on Terracotta. In this episode there are again interesting solutions to remember. Terracotta partnered with VMWare to distribute enterprise Java applications in VMs. The side effect is the one click provisioning model, where instead of the tarball you install an image that freezes completely the environment so you don’t need to fight with compatibilities issues. It also turns out that multiple instances of the same app running on the same big server is a better hardware optimization than having the same instances running on different physical hardware. So instead of 100 servers, maybe you have only 20 running 5 VMs each with the same image. Now this has nothing to do with Terracotta in specific, it’s just their actual selling pitch. The Ruby hosting world has indeed moved to the same model, calling them slices, dynos, nodes and so on.

The Web 2.0 Show - Episode 19 - David Heinemeier Hansson… Once again I enjoyed listening to the story of DHH and 37Signals flagship products. This time I heard a little more about the personal history starting from the 2000 or around. It’s inspiring and motivational. The idea I got about the success of Rails is that is based on pure execution, that is, given a technology that doesn’t get in your way and an idea on how to improve a bit the quality of life, a pragmatic approach makes it a success no matter what. Doh, sure that is a known fact, but VCs and the Valley style pushes to another direction. DHH gives a good reason why it’s time to start a software business: it requires just your time, the hardware is cheap, an office is less important when the network enables distributed collaboration easily. In other word, you don’t need a huge investment to start with, just 3 months of your nights and weekend. Of course is not easy, but at least you know that depends just on you.