It looks obvious

The last few days were pretty hectic, and it is going to be somewhat crazier in the days to come. An important project, with crazy deadline, requires most of my attention for the next few days. Not surprisingly, more than I’m missing updating this blog I’m missing reading others. The reading backlog is simply unbelievable…

 And, by the way before I’m disappearing to do what I’m paid to do, go and help Ron Paul’s efforts to complete a $500,000 by the end of the quarter. It is a good cause.

If you ever wondered what happen when the process takes first priority and the organization become purpose for itself, instead of what it produce - go and read this:

So that nets us a conservative estimate of 24 people involved in this feature. Also each team of 8 was separated by 6 layers of management from the leads, so let’s add them in too, giving us 24 + (6 * 3) + 1 (the shared manager) 43 total people with a voice in this feature. Twenty-four of them were connected sorta closely to the code, and of those twenty four there were exactly zero with final say in how the feature worked. Somewhere in those other 17 was somebody who did have final say but who that was I have no idea since when I left the team — after a year — there was still no decision about exactly how this feature would work.
By the way “feature” is much too strong a word; a better description would be “menu”. Really. By the time I left the team the total code that I’d written for this “feature” was a couple hundred lines, tops.

Technorati Tags: Feature Creep - Program Management - Bureaucracy - Process - Agility

Although I have strong reservations from a methodology suggested in this post, suggesting to give the developer the work and to get the results when they are done - when ever this lucky day arrives, I just love this quote:

if you start with an Agile Methodology, and you add enough hard work, you get a bunch of work done. Go figure.

Technorati Tags: Agile software development - Project Management - The Silver Bullet

The rest of us have all known that Agile Methodologies are stupid, by application of any of the following well-known laws of marketing:
- anything that calls itself a “Methodology” is stupid, on general principle.
- anything that requires “evangelists” and offers seminars, exists soley for the purpose of making money.
- anything that never mentions any competition or alternatives is dubiously self-serving.
- anything that does diagrams with hand-wavy math is stupid, on general principle.
And by “stupid”, I mean it’s “incredibly brilliant marketing targeted at stupid people.”

Agile programming , with its many different flavors, become more than just a buzz word. As many positive solutions Agile development has its advantages when applied in the right environment and when solving specific projects. However as many “silver bullets” it has its problems.

Steve Yegge’s witty and thought provoking post discussing some of these weaknesses. But it does more than just that, it suggesting an alternative: its current work environment at Google. It isn’t short post, and with the discussion that follows the post it is actually very long - but it is worth the time.

Technorati Tags: Agile software development - Project Management - Google

I discovered recently another great programing blog. Each of the post is a good source of knowledge and experience and require active thinking of the reader. Here for example a post about Distributed Information Systems:

1. People tell the truth.
2. Content is independent of presentation.
3. Syntax doesn’t matter.
4. Identifiers are reliable.
5. Metadata and data are consistent.
6. Schema ensure interoperation.
7. All the data must be available.
8. Canonical models can be determined.
9. Index latency is zero.

Developing applications for a corporation I made, and so other make, each one of these fallacies. I wonder if I understood the list the same way before seeing all of this mistakes and their result happening…

I find this hilarious description of the technical documentation process in coding horror, along with labnotes, my favorite blog about programming.

One of the few things I learn in management in general and in software development in particular is that there is no one solution to rule them all. We, as managers, should have in our arsenal as many methods as possible and the common sense when to apply them. This practice isn’t applied only to management; it applies to software development as well.  A good development team should have the ability to use different methods and the selection is best of analysis which solution will be the best to solve specific problem.

I don’t think that what I’m writing here is earth shattering to any professional. But I’m writing it as a response to a post I read today on Signal Vs. Noise , the blog of 37Signals . For awhile now the writers on this blog, and the creators of very successful and useful project collaboration service, preaching for agile methods.

I have no problem with the agile software development methods, and I’m using them myself. However like many other methods, this one is another method in my arsenal, not the Holy Grail.  Any method has its limitations and applying it everywhere, as universal solution, would be a mistake. But I guess that professionals would know that…

Link:  “Professional” is a buzzword

It seems like it’s time to call a spade a spade: “Professional” is a buzzword. It doesn’t mean anything anymore. Disagree? What does Professional mean to you?

Short, sharp and completely to the point description :

For some people, the art of using Microsoft Project and Outlook while sitting around all day in an office.

For the ones who actually intend to accomplish something, it’s the art of doing more things with less resources in the most efficient way.

Steve McConnell’s book “Rapid Development ” was, and still is, a must read book to anyone who manage software development.

Dealing with software development and with software project management this book is one of the best guides I ever had (together with PMBok ). Yesterday I discovered Steve’s web site with references to his books and articles. I recommend adding it to your favorite bookmark list.

In the “Rapid Development” section Steve McConnell provide very useful excerpts. Here for example the summary of classic mistakes done in software development, and other type of, projects. As one that made more than one of these mistakes, and was witnessed for other making a handful of them too I can attest to the usefulness of this list.

The following cartoon, published by Scary Ideas, is an accurate description of the reality.

Project Management , I.T. , Software Development