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!

Funny quotes about computers and programmers. Enjoy!

“How many hardware engineers does it take to change a light bulb?”
None: “We’ll fix it in software.”

“How many software engineers does it take to change a light bulb?”
None: “We’ll document it in the manual.”

“How many Microsoft engineers does it take to change a light bulb?”
None: “Let’s define darkness as the industry standard.”

“How many tech writers does it take to change a light bulb?”
None: “The user can work it out.”

Anonymous

—

Line Printer paper is strongest at the perforations.

Murphy’s Law of Line Printers

—

The goal of Computer Science is to build something that will last at least until we’ve finished building it.

Anonymous

—

Every program is a part of some other program, and rarely fits.

The Complete Microsoft Internal Jokes, Vol.III

—

When the program refuses to work as intended, change the specification to fit the program. It’s easier than vice versa.

Briefing for new programmers joining Microsoft, 1995

—

Information Center, n.: A room staffed by professional computer people whose job it is to tell you why you cannot have the information you require.

The Devil’s Dictionary to Computer Studies

—

If the code and the comments disagree, then both are probably wrong.

Norm Schryer

—

Every program has at least one bug and can be shortened by at least one instruction – from which, by induction, one can deduce that every program can be reduced to one instruction which doesn’t work.

Anonymous

—

God made machine language; all the rest is the work of man.

Anonymous

—

Real Programmers don’t write in PL/I. PL/I is for programmers who can’t decide whether to write in COBOL or FORTRAN.

Programmers’ World

—

The C Programming Language: A new language which combines the flexibility of assembly language with the power of assembly language.

Murphy’s Introduction to C

—

A language that doesn’t affect the way you think about programming is not worth knowing.

Alex Lu, commenting on Java Programming

—

At the source of every error which is blamed on the computer you will find at least two human errors, including the error of blaming it on the computer.

Anonymous

—

I expect that any day now someone will invent a round thing which rolls along the ground and minimizes friction, only it will need a 233-megahertz Pentium processor to do it.

Garry Harant, Blackburn, Victoria, Australia

—

The world is coming to an end. Please log off.

Posix 2.1.1 System Shutdown Message

You can find more here and here. Have fun!

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.

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.

The magazine is devoted to the quality assurance in the software development field and has the ambition to present some of the best authors in that area. I am really proud to be one of them! The articles are very good and Quality Matters raises the bar very high with its first issue. I wish the publishers faith and devotion to keep it valuable and useful. I hope that I will have again the opportunity to write for the magazine in the future.

Don’t miss it!

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.

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.

I notice when I talk about Business Analysis people often have a very fuzzy idea of what I’m talking about. And the deeper I go into defining the profession from a general perspective, the fuzzier it gets.

That’s why I decided to write down the things I personally do on a day-to-day basis, and I hope this will help build a better picture for the uninitiated. Other BAs might do different things, but usually there a level of similarity, otherwise there would not be a name for the profession.

1. Documentation – Most known and usually most tedious BA activity. The problem I’m trying to avoid with this is to have 5 team members and 3 major stakeholders and amongst them 15 different ideas what we are actually doing. The Business Requirements Specification is a tool for avoiding this, but not the only one and often falls short of achieving the objective.

2. Process Analysis – I don’t do enterprise analysis, at least not on my current position. What I do is more focused – when we change the systems people will change their work process. What I’m trying to describe is how things are done now (the AS-IS point of view) and how the work will be done after the change (the TO-BE process). The purpose here is to demonstrate to the team what the changes we are making will actually achieve. It also visualizes in front of stakeholders in detail what business result they have requested.

3. Requirements Elicitation/Analysis – A key task in my job, this is the description of what system changes we are actually going to make. The task here is to translate the general and unclear requests into detailed description of what is needed and is going to be done. I need to be at least somewhat familiar with the current system designs, since some (actually most) initial requirements are unreasonable and waiting for the developers to tell me that takes too much time.

4. Requirements change management – Extremely unpleasant topic for all involved. Means that me and the stakeholders have forgot something or a stakeholder has simply changed their mind. So we need to reanalyze all the wok done so fore – requirements dependency, project scope and price, requirements documentation and communication. Since most of the team works on many projects at once and we have no constant communication, spreading the new information to everyone is a demanding task.

5. Priorities – All requirements matter but some matter more.  With limited resources at disposal my work includes proposing or making decisions related to what will be developed now, what will wait the next development cycle and what will be done in the bright distant future when the world becomes a perfect place and all our wishes come true.

6. Project Management – I highly value PMs for all they do – organizing meetings, taking hard decisions, negotiating deadlines, monitoring deadlines and so on. Most often, however, I have the dubious privilege to substitute for them. Since as a BA I have clear picture of requirements and keep constant contact with stakeholders I am the usual suspect for filling the role of PM for the project. If you ever need to convince someone it’s important that each project has a PM – let him substitute for a while and he/she will quickly come around. I guess that’s the reason PMs are the strongest supporters of the BA profession – for similar reasons they do our job when we are not around.

That’s all I can thing of on the spot. If you can thing of things you do as a BA (and probably me too, but can’t recall at the moment) feel free to add to the list.

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.

First point of the author is that top-down planning is old style. He says:

Top-down planning makes the assumption that upper management has the best processes and ideas to run a project smoothly.

I think the author confuses planning with management. Top-down planning means dividing the project’s work into several big parts, then each parts is divided into smaller parts and so on until we reach small enough tasks that we can estimate and assign to somebody. Nobody said that it has to be done by the upper management although I believe that the first steps in dividing the work should be made by the project manager not because she has the best ideas but because she has the best view of “the big picture”.

The second point is that top-down planning could reinforce the “Peter Principle”

The “Peter Principle” says that individuals are promoted until they reach their level of incompetence, at which time the promotions cease. As the author explains it, people are promoted until they start doing a bad job, and then they are left in that position until retirement or until they quit.

First, this “principle” is kind of corporate humor so it doesn’t happen all the time in reality. Second, before they are promoted to the level of their incompetence, the skillful project managers are at their best position and they do their job the right way. And third, even if the PM is incompetent, they have a team of trusted people on which they can rely to make the plan together.

The same argument stays about the third point of the author: top-down planning limits buy-in from the team because the project manager wouldn’t allow them to participate in the plannig process. I will repeat: planning is not managing and it is not necessary that the project manager makes the plan by herself. Top-down planning is about how to make a plan, not about who makes it.

I am not saying that top-down approach in planning is the best way to do it but definitely it is not a wrong approach by definition. Whether it is right or wrong depends mainly on the team expertise, the technical experience they have and the knowledge about the business area.

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.

It is intersting to notice that giants like IBM and HP are always “subscribed” to charts like this while Microsoft, for example, is missing. What impresses me most is that a great part of the companies Jim Collins analyzes in his books Built to Last and Good to Great are present in this list. This means to me that he really found the right ingredients for creating a great company and I strongly recommend you these books.

Take a look at this chart and I will be glad if you share your comments about the companies enlisted.

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 can buy a person’s hands, but you can’t buy his heart. His heart is where his enthusiasm, his loyalty is.

- Stephen Covey

Of course, it is the most difficult thing to do – to win someone’s heart – but I believe that it is the best way to win their loyalty and devotion.

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.