The SmartBear company celebrates the version 5.0 of its product CodeCollaborator and makes a great offer to sell 5 licenses of its lightweight product CodeReviewer for only $5!

This offer will be available for only 5 days: July 13-17, 2009 only.

I was very interested in the offer and made the effort to read a little more about the product. It seems to be very useful if you practice code reviews in your company. And if you don’t – you probably have problems in your code.

For $5 you don’t get the full-featured product CodeCollaborator but its “younger cousin” CodeReviewer, which has quite less features. You can see the differences between the two products here but you can easily see that features that CodeReviewer has are quite satisfying for any team that wants to improve their code writing practices and the price is totally worth it.

Don’t miss this amazing opportunity!

You may also find these posts interesting:

• My First Article In Quality Matters Magazine

Long time ago, at the dawn of the computer era there were funny legends about The Real Programmer who writes only in FORTRAN, drinks a lot of coffee and beer and NEVER, I mean NEVER writes comments. Today the things are different and the programming is not that mystery magic it used to be and all bosses respected. Today even the children know how to click on the keys and how to write program code even before they know how to write pothooks in their notebooks.

The same logical process happened to the evaluation of the Real programmer’s qualities. It is based on a scientific ground and there is nothing subjective or accidental anymore. A psychological test have been developed that determines your programmer’s personality. The authors claim that it is based on Myers-Briggs tests and that it is absolutely serious although I found some of the questions very funny.

Here are my results. They are no surprise to me but it proves that I know myself very well. Now anyone can see my programmer’s personality.

Your programmer personality type is: PHTB

• You’re a Planner.
  You may be slow, but you’ll usually find the best solution. If something’s worth doing, it’s worth doing right.
• You like coding at a High level.
  The world is made up of objects and components, you should create your programs in the same way.
• You work best in a Team.
  A good group is better than the sum of it’s parts. The only thing better than a genius programmer is a cohesive group of genius programmers.
• You are a liBeral programmer.
  Programming is a complex task and you should use white space and comments as freely as possible to help simplify the task. We’re not writing on paper anymore so we can take up as much room as we need.

Do you want to find out if you are a Real Programmer or just a team player like me – do the test! It is quick and easy and doesn’t hurt.

Thanks to Doncho for the great link!

If you like the posts in this blog or you are interested in the discussed topics, please, subscribe to the RSS feed to guarantee yourself that you won’t miss an interesting post. You can do it in an RSS reader or by Email.

You may also find these posts interesting:

• The Project Management Theories According to Bas de Baar
• My First Article In Quality Matters Magazine
• The 15 Commandments of the True Leader
• Recommended Readings: Project Risk Management
• The Mythical Man-Month Walkthrough

His blog is devoted to project management and he has original ideas about how to manage people. I think he believes that we lack some thinking and understanding for the others and this is why I feel his blog so close to my blogs PM Stories and Stop and Think!. And probably this is the reason why I like his blog so much.

Read the interview here. You may find some food for thought.

If you like the posts in this blog or you are interested in the discussed topics, please, subscribe to the RSS feed to guarantee yourself that you won’t miss an interesting post. You can do it in an RSS reader or by Email.

You may also find these posts interesting:

• Top-down Planning – Good or Bad?
• Walking on Water
• The Most Important Rules of Delegation
• Project Management and Hiking
• The Recommended Weekly Readings (2007-08-18). Project Management

Build in Asia
Design/Review in Europe
Test in South-America
Every day.
Every 24hrs.

Well, I am starting to believe that this is a great way to speed up the process but a small devil in me asks this stupid question:

What if at some point you need to talk with the people from the previous time zone?

Suppose you found something that you don’t understand in their specification or in their code, or it seems to be wrong. You want to discuss the issue with your offshore colleagues but their working day is over and they went home. Now you have to wait until tomorrow.

I think that the time difference is a huge problem in communication and although following the sun seems to be a good idea it is not a panacea and you have to develop a strong process to ensure communication abilities without disturbing the personal life of your staff.

There is one more great article Bas wrote on offshore software development that I highly recommend: 25 Rock Solid Tips to Supervise Offshore Development. Read it and follow those tips – they are really helpful.

If you like the posts in this blog or you are interested in the discussed topics, please, subscribe to the RSS feed to guarantee yourself that you won’t miss an interesting post. You can do it in an RSS reader or by Email.

You may also find these posts interesting:

• Top-down Planning – Good or Bad?
• How Can a PM Become a Real Leader?
• The Two Types of Programmers
• What Kind Of Programmer Are You?
• Classic Mistakes 2008

Walking on water and developing software from a specification are easy if both are frozen.

Thanks to Irina Marudina for this piece of wisdom.

If you like the posts in this blog or you are interested in the discussed topics, please, subscribe to the RSS feed to guarantee yourself that you won’t miss an interesting post. You can do it in an RSS reader or by Email

You may also find these posts interesting:

• Krishna Kumar Did An Interview With Me On Software Development

He says that there are two types of programmers – Type 0 (20%) are the people who program for fun. These people live programming, they breathe programming. They use Linux and they contribute to Open Source projects. In other words (although he doesn’t say it), these are the good guys, the smart guys. The other group are Type 1 (80%) – people who practice programming for living. They work from 9 to 5, they use only Microsoft technology and they don’t read the technical news. “They are not stupid”, he says but I believe it is just what he means because the final appeal is to the smart guys to swallow their pride and to hope the stupid guys become smarter.

If you feel that you belong to the Type 1 programmers, the stupid ones, don’t worry – one of the most important characteristics of the 20% group is that they read blogs, especially Jeff’s one. So you just need to read one article of his and you’ll automatically become a member of the elite group.

Sorry Jeff, I don’t buy it!

I would agree that we can separate the programmers into two groups – one for the people who like programming for the sake of the programming itself, and another for the people who provide value with the applications they write. But this definition is so archetypal that it doesn’t bring much of a value. And claiming that the developers belonging to the one group are smart and the others are dumb, is not only insulting, it is just wrong.

First of all, I have never seen a programmer, who had never read a technical web site or a blog. Second, nobody has counted the programmers and there is no evidence that the ratio is 20/80. I believe the numbers are just taken from the Paretto principle without any backup survey. Third, to accuse someone for being stupid just because they value their private time or because they use Microsoft technology, is just flaming another religious war.

The software development is a business like any other. It is important and powerful one. This business needs the two types of people – the ones who love the process of programming, who create and invent new ideas and new solutions, and the ones who make those ideas reality, the ones who implement the customer’s requirements and bring real value to them. Perhaps the real ratio should be 20/80, or 10/90, or whatever – it depends on the business area. The point is, all kinds of developers are valuable because they bring value in different ways. Their diversity is their richness.

You cannot call someone stupid or inexperienced only because he or she doesn’t write code during the night or because they write in Visual Basic .NET. One is inexperienced because she lacks experience. An if you are more experienced you can help them by sharing your experience and by showing them good sources of information. People learn and people change and very soon they will have more knowledge and more experience and will be professionals just like you.

This post is also available in Bulgarian language. 

If you like the posts in this blog or you are interested in the discussed topics, please, subscribe to the RSS feed to guarantee yourself that you won’t miss an interesting post. You can do it in an RSS reader or by Email

You may also find these posts interesting:

• Funny Computer Quotes

You can download the book from its website – The Software Conspiracy.

Glenn Alleman of Herding Cats points our attention to the Department of Defense version of the Guide to Project Management Body of Knowledge (PMBOK® Guide). It is a better source of knowledge he says and more than this – it is free. In fact it is called “DoD Extension to PMBOK® Guide” and as they say in the preface:

The primary purpose of this document is to identify and describe defense applications of the core project management knowledge areas contained in the PMBOK® Guide, as well as those defense-intensive knowledge areas not contained in the Guide. It is important to understand that this is an extension to the PMBOK® Guide, and is not intended to be a stand-alone document.

Anyway, the document is free to download and I believe it could be useful source of knowledge to the practicing project managers.

And, at the end, a free e-book from one of the greatest software gurus – Ed Yourdon. His book Death March is still in my personal Top 10 list of all time influencing books on software development.

Craig Brown of Better Projects brought the link to the free e-book Just Enough Structured Analysis to my attention. He says:

[Yourdon] over time has migrated from a view that highly structured processes will improve project results to one where he believes the success factors are quality people and in keeping bureaucracy out of the way.

Ed Yourdon is a world class expert on software development and the book is definitely worth reading. He says in the Introduction:

This book is intended for two audiences: first, the person who is new to the field of systems analysis, and, second, the experienced systems analyst who needs to acquaint himself with systems modeling tools and techniques that have evolved over the past decade.

Happy reading!

You may also find these posts interesting:

• The Pros and Cons of Distributed Teams
• Follow The Sun – Tips For Offshore Development
• Walking on Water
• Funny Computer Quotes
• Project Management 3.0

I thought a long time before deciding to write something about it.

Why is it so difficult for me to write about successful products? Well, mostly because I spent most of my professional life working at project-oriented companies. Most of the projects I participated in were one-time shots and I don’t know what happened to those products – if they were ever used or if they were successful. And I can say that most of the companies operating in Bulgaria are outsourcing companies working this way. It is not their responsibility to care about the product. They only care about the current project – to be delivered on time, within the budget and within the defined scope.

I have also worked in some product-oriented companies but they were so small and so poorly managed that most of them soon bankrupted. I know about only one of them which still functions.

So it was a really big challenge to think of some example of a successful product and one of the most important questions I asked myself was “What is the definition of a successful product?” I think the only answer to this question should be “a product that makes the customer’s life easier and is used for a long time”. So, I finally decided to tell you about one of my experimental works with my own company. It is a “successful product” because it was developed almost ten years ago and is still in use and is of great help to the people who work with it.

The story started in the beginning of 1998. There was a need of a software product that calculates the debt of some companies that had taken a loan from a government agency. The problem was that the rules of calculating the interests were very complex and it was not easy to be done with common tools like a calculator or even a spreadsheet. So I wrote the program. Well, I didn’t do it alone – I had a small team of partners who comprised the development team over the years.

At the beginning it was a simple program, then the customer added more functionality, then it was branched into several product for the needs of different kinds of users, and so on. I managed all the changes to happen as different projects so I didn’t suffer a scope creep. On the contrary – it was a perfect example of well-developed developer-customer relationship.

These days a major change happened – the customer decided that a serious change in the algorithms is needed and having in mind the age of the initial product we decided that we should develop a new version using a new technology and a new architecture. So we started a new project and I am currently working on it. It is close to completion and the users are already using its beta version and are very happy because they have a good tool that helps them significantly improve their performance and saves them a lot of time.

Why it turned to be such a success? Well, I think it’s primarily because I paid a lot of attention to my customer’s worries. I was very patient to listen to them although it sometimes wasted a lot of my time but they build their trust on me and once they knew that I was the only person who understands their business they started to consider me not as a servant but as a partner and as a friend. I never had problems with sign-offs and with payments and for me the only explanation for this is the trust we build in each other. We always thought that this relationship is a win-win kind of relationship and that notion made it possible to conduct all our projects successfully and finally to get a successful product.

Unfortunately, this one of the very few examples I have of successful products. In many other cases we delivered the product to the customer and then closed the relationship with them. Building a long-term relationship based on trust and accountability is a very difficult thing and few companies succeed in that but only they later become the market leaders. I think this is the only way to succeed in the business.

I don’t want to tag other people. I read some people’s blogs on software project management but Craig has already tagged them. So I would like to invite anyone who reads my blog and has a good story of a successful software product to share it in his or her blog and to link it to this post and to Craig’s post. Good success stories are much fewer than the examples of failure so it is important for us all to know them. Just to improve our belief that success is possible – you just have to think about it!

You may also find these posts interesting:

• How Did You Become a Project Manager – Survey Results
• A "Classic" Story of Classic Mistakes by Steve McConnell
• Top 10 Mistakes in Software Development, According to InfoWorld Tech Watch
• CIO Top 100 Companies For 2008
• Recommended Readings: Free e-book downloads

It is worth it!

You may also find these posts interesting:

• Recommended Readings: Project Risk Management
• Walking on Water
• Full Time Pay for Half Time Work?
• Follow The Sun – Tips For Offshore Development
• How do you estimate the project’s budget? A new poll

The question this month is: How do you estimate the project’s budget? My personal observations are that in the software companies in Bulgaria the project managers are not allowed to deal with the budget. The financial estimates are made by the top management and usually are kept in secret from the team, sometimes even from the project manager.

I am very curious if this practice is used elsewhere.
Please, vote! Your opinion matters!

You may also find these posts interesting:

• Classic Mistakes – GigaLease Case Study, Part 2
• Classic Mistakes – GigaLease Case Study, Part 1
• My day-to-day work as a Business Analyst
• Techniques for Gathering Requirements
• The Mythical Man-Month Walkthrough