Programmer’s Day

Posted by Mike Ramm on September 13, 2007

I was reminded today about the “unofficial” Programmer’s Day. I don’t think there will be an “official” day ever. And in fact, I don’t think anyone cares. What is more important is just to have more reasons to celebrate! And we love to celebrate!

The logic about this day is that September 13th is the 256th day of the year and 256 is very important number for the programmer’s brotherhood. It’s a great idea but I’ve also heard about the 128th day of the year and why not celebrate the 42th day? It’s hardly possible to find a programmer who doesn’t believe in the magical nature of the number 42

Long time ago, when I was a first-year student in the University, me and my company defined another date to be the programmer’s day and it was defined with and algorithm! We announced the programmer’s day to be the first Saturday of April when it’s not the first of April (simply because it’s another holiday ). If the first Saturday happens to be on the first of April then the programmer’s day would be on the eighth of April. Why did we choose that time? Well, because then the weather becomes warmer, the spring is coming noticeably and you can go on a picnic in a fresh air. We may be programmers but we are not moles and we value the sun and the air like everyone else.

So, today is a holiday and it should be honored.
I congratulate all the colleagues working in the field of Information Technologies and everyone who feels like a programmer on The Programmer’s Day.

Happy Programmer’s Day! Cheers!

Tags:
Filed Under Fun, Software Development | Leave a Comment

The role of the Business Analyst – poll results

Posted by Mike Ramm on September 11, 2007

I wrote a post in Bulgarian about the role of the business analyst in a software development team and I put a poll to survey how the people in the software development business in Bulgaria evaluate it. Now the poll is closed and I am giving you the results.

Question: How do you evaluate the role of the business analyst in your team?
Total votes: 27 (little but I still have few readers).

Answers:

Very important role. The BA investigates the customer’s needs and represent them before the team – 14 votes (52%)
All roles are equal. The BA is responsible for the functional (requirements) specification, which the developers implement – 6 votes (22%)
We don’t need such a person. The developers do the client’s business analysis themselves – 4 votes (15%)
What is a “business analyst”? – 3 votes (11%)
He just hangs around here and looks silly. He cannot write a simple JavaScript – 0 votes (0%)

How to interpret the results? Obviously, the first thing that has to be noted is the small number of the votes. For me, the main reason is the fact that still very few people visit my blog and most of them weren’t impressed by the poll. I think I will open it again in the future when there will be more visitors to my blog.

Anyway, the good news is that despite the few voters, the results show that the position of the business analyst exists in the software teams nowadays and it is appreciated positively. No matter if considered as very important (answer #1) or considered equal to all the others (answer #2), the business analyst takes his/her well-deserved place in the software team (totally 20 votes for both answers, which gives around 74%)

Answer #5 is rude and represents the vulgar and arrogant attitude of some developers to the surrounding world that doesn’t write code. I am glad that nobody voted for it. It probably means that this attitude was already buried in the past.

Answer #4 is a little silly. How can you be a self-respecting developer and not know what a business analyst is? I put this answer on purpose with the intention to be chosen for fun and to make the poll more colorful. I believe that this was the intention of the three guys who voted for it. And if they really don’t know what this is – keep on reading here – there will be more posts devoted to the job of the BA.

The most interesting answer for me is answer #3. It has a double meaning. There are companies, on one hand, that work on small projects or such that work on products and don’t use project principles at all. In such companies, every developer, having been working long time on the same product and having been communicating with the field experts from the business area being automated, gradually begins to gain exactly that knowledge and experience, which make him or her a business analyst. And if you add the aspiration of the company for more exploitation of its employees we come to a natural merging of the role of the BA with the role of the software developer in one person.

However, there is another interpretation. The team (or the company) could consist only of “great programmers” – people who think they know, understand, and can do everything. It was the ideal of the past socialist society in Bulgaria – so called “multi-dimensionally developed persons” – people who believe that a developer should be skilled in every aspect of the software business and there is no need of a narrow specialization in particular areas like business analysis, project management, testing, user education, etc. The developer can do everything!

I really would like to know what were the reasons to vote for this answer. I hope some of the voters will post a comment about it. And if you have an opinion about the role of the business analyst in your team – please, share it with me. It will be useful.

Tags: business analyst, poll, role
Filed Under Business Analysis, Polls, Software Development, Teamwork | 2 Comments

Project Management and Hiking

Posted by Mike Ramm on August 26, 2007

Hiker Glen Alleman wrote a great post in his blog Herding Cats entitled Agile Planning. There he makes an interesting comparison between the hiking “projects” and software ones and asks serious questions to the adherents of the Agile methodologies.

He says:

Hiking requires Planning and Scheduling and Execution. Alternative plans are needed, alternative schedules always happen and alternative execution choices are always there. So what’s all the noise about Planning and Scheduling in agile software development?

And more:

Preparation is the key to a successful hike

Why wouldn’t…
Preparation be the key to success for a project?

To argue otherwise – that planning, preparation, sequencing, and execution performance management – is not needed is dangerous in the hiking paradigm. Why do we think these activities are not important in the project management paradigm?

Good questions to ask ourselves and especially those religious fanatics who claim that their extreme approach with no planning is always a better solution than the traditional management methodologies.

Read the whole article he re.

Tags: hiking, planning, Project Management
Filed Under Project Management, Software Development | Leave a Comment

Top 10 Mistakes in Software Development, According to InfoWorld Tech Watch

Posted by Mike Ramm on July 22, 2007

There was a post in InfoWorld Tech Watch entitled 10 mistakes to avoid in software development where they quote a Forrester Research report published recently. While I think that, generally, the list of mistakes they published is really important to the success of every project, I will go into more details with each one of these mistakes and will give you my opinion on them.

Here they are, the 10 mistakes we should avoid in software development:

Never committing to project success. This is too obvious, I don’t see any wisdom in it.
Freezing the schedule and budget before a project is sufficiently understood. Unfortunately, this happens everywhere, every time. In my opinion, this is the main problem of the software project management: What to do when you are asked to give estimates about the cost and the time, and even to sign a contract before you know what this project is about?
Overscoping a solution. Yes, this is a mistake but I believe it happens more and more rarely.
Circumventing the application development organization altogether. I don’t think it’s a mistake if you know what you are doing. Sometimes it is the necessary if you’ve been assigned to a “Death March” project. The real question is: Can you still manage to succeed?
Underestimating the complexity of a problem. Usually, this is the reason for signing contracts with low budgets and shortened schedules. Unfortunately, this mistake is mostly made by the upper management mostly because they don’t consult with their team. I believe, that every company should invest some time upfront to investigate the customer’s problem ti gain a better understanding of its complexity.
Being stingy with subject-matter experts, in which their participation is not sufficient. I think this is also a result of the previous one.
Choosing the wrong project leadership. Or the wrong leaders. Or the wrong managers. Or the wrong customers (Can there be wrong customers?)
Distrusting managers who have had tasks delegated to them. I would say that not trusting anyone in your team or company is a mistake.
Jumping into development without enough research. Again, it happens as a result of underestimating the problem.
Suppressing bad news, in which dialogue is insufficient. Do you know a manager who likes to hear bad news?

Well, some would say that I am too skeptic or that I am a naysayer. No, am not. I think there are a lot of problems in our industry but this is my profession and I love it. I really want to discover the biggest mistakes we make, to analyze the reasons for them and to make a plan how to avoid them. Which is really hard. And when we look at our mistakes we just need to be more specific, especially when looking for the causes of those mistakes.

Tags: Classic Mistakes, forrester research, software industry
Filed Under Classic Mistakes, Death March, Software Development | Leave a Comment

← Previous Page