Walking on Water
I found this great sentence, which belongs to Edward V. Berard and I am eager to share it with you:
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
Filed Under Fun, Software Development | 2 Comments
The Most Important Rules of Delegation
I found recently an article by Richard Lannon entitled 12 Rules of Delegation. While the article is fine and it really gives some insights on how to delegate I think it fails to emphasize the most critical issues of delegating responsibility to the others.
I started thinking and looking for some more blog posts on delegation and I came to some conclusions which I would like to share here with you.
Delegation is a two-way street, says Richard Lannon. Yes, this is an important thing that we shouldn’t forget. And when we assign a task to someone and we hold them responsible for it we have to have in mind our reasons to delegate and their reasons to accept it.
What are the issues from our perspective? There are two major questions we must ask ourselves: Why to delegate? and What to delegate?
Filed Under Leadership, Links, Teamwork | 8 Comments
Rich Maltzman, Crowdsourcing, and Project Management
Rich Maltzman is a certified PMP and a project manager with huge professional experience. I didn’t know him until recently I found the Fiddler on the Project Wiki where he tries (together with Ranjit Biswas, PMP) to write a book based on the principles of crowdsourcing. While I didn’t know anything about crowdsourcing either, I started looking around and I found that generally crowdsourcing is a way to create something with the significant help from the crowd. Fiddler on the Project is an experiment in using crowdsourcing to create a book on project management with the help of a hundred participants. Intriguing, isn’t it?
Filed Under Links, Project Management, Teamwork | 3 Comments
The Two Types of Programmers
Jeff Atwood at Coding Horror wrote a post called The Two Types of Programmers, which gained a lot of controversial comments. Then he wrote another post trying to explain what he meant in the first one and to bring up the peace but the war has already started. I read them both. I read them many times and I still don’t understand what exactly he meant.
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!
Classic Mistakes 2008
I just received an email from Steve McConnell with the results from the last summer survey about the Classic Mistakes of the software development. I already wrote about this survey in my post Classic Mistakes Forever. Steve published his list of Classic Mistakes for the first time in 1996 in his book Rapid Development and due to the dynamic changes of the software business, last year he decided that this list need some actualization.
Now he publishes the results of this survey in a 39-page white paper along with a PowerPoint presentation. There were a lot of questions in that survey so the authors can make a deeper analysis of the nature and the origin of the biggest mistakes we make in software development. The Classic Mistakes list of 2008 has them ordered by the frequency of their occurrence and by the impact they have on the project team to deliver software on time. Mixed together these criteria give us the list of most damaging classic mistakes of our business. I will not tell you which is the most damaging Classic mistake we make - I don’t want to spoil the pleasure of reading it by yourself - just follow this link (it may require free registration) and you will know it.
My professional experience shows that most of the companies that do software development are too far away from the standards Steve has set for Rapid Development and the first and the most important step they need to make is to avoid making those Classic Mistakes. You have no chance of finishing your project on time unless you stop making such mistakes. I strongly believe that every good software project manager should have this list in front of them and should check it regularly asking themselves: Are we making Classic Mistakes? How can we avoid them?
It is not easy, of course. Sometimes you must do things classified as Classic Mistakes forced by the circumstances or by the upper management. But knowing that what you do can lead you to a big trouble will make you be more careful in your actions and to pay a better attention to the risks that are threatening you.
This white paper is a priceless source of information. Read it and think about your projects.
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
Filed Under Classic Mistakes | Leave a Comment
The Pros and Cons of Distributed Teams
I got this article recently, called 5 Reasons Distributed Teams Suck. This is an answer to another article that argues that distributed teams are great and gives us 5 reasons for that. The funny thing is that using the same arguments both authors come to different conclusions. For example:
Reason Number 5:
Pros: It saves energy. While you work at home you don’t waste time and effort for traveling.
Cons: It wastes energy. When you have to travel, you waste a lot more than if you worked in the same country and in the same office.
Where is the problem? Why these guys think so differently upon the same situation? My answer is very simple. The very definition of the “distributed team” they use is different.
When I ask myself the question “What does a distributed team mean?” I divide it into the following questions:
1. How distributed is the team? If the team works in the same town and they don’t work constantly in the office but instead they work at home I believe it really saves money and energy and this kind of distributed team works effectively because they don’t spend time traveling, they use their own computers and they only need a good internet connection to do their work (especially if the team doesn’t need any other special technical equipment). But if the team is disbursed through the globe then it might not be cost-effective at all. Especially if there are long time differences and there is a need to meet face-to-face frequently.
Filed Under Peopleware, Teamwork | Leave a Comment
Time To Say "No" And Time To Say "Yes"
We all know what monster a scope creep can become. We all know that the good project manager should know when and how to say “No” to the attempts of unnecessary scope changes that lead the project to inevitable schedule slippage. But it doesn’t mean that we should say “No” all the time to everybody.
I got involved in a project recently where the official policy of the company was to say “No” to all the customer’s requests. The project management responsibilities were shared between several people but not one of them liked to take responsibility for any decision so it became easier to all of them to say “No” instead of considering the customer’s request.
Filed Under The Role of the Project Manager | Leave a Comment
Who Does Money Really Motivate?
I’ve been a manager for quite some time and I have always wondered how to motivate my people to work better but I have never got a good answer. Until recently, when I read Pawel Brodzinski’s post Money as a Motivator and David Carr’s 7 Reasons why Money is not the best Motivator. Pawel also referred to Rob Walling’s post Nine Things Developers Want More Than Money.
We all know Frederick Herzberg’s Two Factor Theory. There are motivation and hygiene factors that drive our job satisfaction. Here is my simple understanding of them:
- motivation factors drive us to work more, to perform better, to be more creative
- hygiene factors are the ones that their lack demotivates us and drive us to work less, to perform worse, and to be less productive and creative
Filed Under Peopleware, The Role of the Project Manager | 6 Comments
Recommended Readings: Free e-book downloads
Jeff Atwood of Codding Horror wrote an article the other day called Why Does Software Spoil? where he gave his brilliant thoughts about the feature creep that spoils all software products. I was very impressed because I also have suffered of “feature overdose” and I think I am going to add my comments soon on this topic. Continuing the theme, yesterday Jeff wrote another article, where he recommended the Mark Minasi’s e-book The Software Conspiracy. Here the author examines in great detail the “feature paradox” - new features are used to sell software, but they are also the primary reason that software spoils over time.
You can download the book from its website - The Software Conspiracy.
Filed Under Books, Business Analysis, Death March, Links, Project Management, Software Development | 2 Comments
Software Product Success Stories
Craig Brown of BetterProjects started a meme with the same title and tagged me to participate in it. He was inspired by a Scott Sehlhorst’s post at Tyner Blain.
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.
Filed Under Links, Project Management, Software Development | 6 Comments
-
-
License
The content of this site is licensed under a Creative Commons Attribution- Noncommercial- No Derivative Works 2.5 Bulgaria License -
Admin