Developing Software

I will try in the following to explain my preferred way of developing software. I hope you will find it interesting and useful.


The most important part is getting a capital of trust from the customer right from the beginning, for the sake of all people involved in the project. If there’s no trust, it’s better to run away because the team and the product will get hurt.

Once I get the initial trust, it’s my top priority to maintain it. I look for any sign of misunderstanding and discuss the root issues as soon as possible. I ask for feedback from time to time: How do you think we’re doing? What would you change? Is there something you don’t like about how we do things?

Continue reading “Developing Software”

Product Development

Laurie Young, Robert Dempsey and myself had a conversation about product and customer development. Some of the questions that we asked were:

  • Is Scrum the best way of producing software?
  • Are cycles preferred by developers over flow? (e.g. Scrum over Kanban)
  • How do you tackle starting a product?
  • Does learning ever stop?

and many more.

I think the conversation is interesting because it goes over the self-imposed limits of Agile methods like Scrum or Kanban and discusses individual practices that are the best to use in a certain context and because it has an unexpected ending. So, take your time, listen to it, and if you have anything to share with us please do.

You may also be interested in: my take on developing software, questions about agile that we’d like to answer.

How to Organize A Code Retreat

Here are some of the things we’ve learned about running a code retreat.
We’ve facilitated about 10 code retreats, including one with Corey Haines.The smallest one was with two (yes, two) people and the largest with about 20. Here are some of the things we learned.

Don’t try to convince people

Many developers who took part in code retreats tried to talk to their colleagues or friends and many times their answer was one of “it’s a buzzword”, “it’s not during work hours”, “it’s plain silly” etc. They were disappointed, but it’s ok. One of the core ideas about a code retreat is that the people that come choose to come. It’s on a Saturday, it starts in the morning, it takes all day long, you need to write code and it’s tiring. People coming there really want to come.

Continue reading “How to Organize A Code Retreat”

Unit Testing, Automatic Testing, TDD – Pros and Cons

I had a lot of recurrent conversations over why we should use automatic testing, unit testing or TDD. Through these conversations, I’ve heard a lot of arguments pro and con to these techniques, so I decided to summarize them.

To be honest, I am very passionate about TDD. I believe this technique is a must know for every developer who’s serious about his or her craft. Despite my personal preference, I will do my best to present both sides of the arguments as clear, pragmatic and even as I can. If you spot any mistakes or errors please let me know and I will update the article.

I will split the discussion in a few parts because I feel the arguments can be separated from general to specific.

Continue reading “Unit Testing, Automatic Testing, TDD – Pros and Cons”


You can find here links to some of the most interesting sites and articles that I read.

Paul Graham’s essays – I believe that Paul Graham is a genius. Not only did he left his mark on software development, but he also funded Y!Combinator, a venture capitalism company specialized in technology start-ups, and, as if this wasn’t enough, he writes perfect, both in form and in essence, essays about technology, innovation, education and investment. If you don’t know him, read them – he will change the way you think about the world.

Martin Fowler’s website – I think Martin Fowler is the only software design theoretician who is spot on. Unlike many others, he is realistic about the premises of software development and doesn’t propose ideas and techniques for an ideal world. He coined and described techniques like refactoring, the various types of Domain Specific Languages, worked on patterns without overdoing it and many others. All in all, it’s a must read for anybody who wants to build good quality software within the budget.

No Silver Bullet – Essence and Accidents of Software Engineering – This is a well known article for any serious software engineer. It’s one of the few that touches the fundamental issues of software development, and shows the essential limitation in faster development of software.

The Mythical Man-MonthFrederick Brooks is a software engineer who participated in some of the largest projects of IBM, 25 years ago. He added his remarks in this book, probably the first discussing about the problems that we have when managing the development of a large software system. Most of his ideas prove still true today and serve as a basic building block for any software development organization method. I am still amazed how many companies, at least in Romania, make the same mistakes described more than 25 years ago by Mr. Brooks.

I’m a big Monty Python fan, as many other developers. For those who don’t know, the programming language python is named after them (its documentation is filled with Monty Python quotes) and the word spam comes from one of their sketches. I also liked that they embraced the new media, and provide a youtube channel with their works – which, by the way, also increased their sales.

However, their humour may be hard to digest at first, so here are a few of their classics. Watch these before trying something like the “Monty Python and the Holy Grail” or “The life of Brian”. So, here they are:

And last but not least, my brother’s interesting drawings.