mamafufu Q: how is life? A: mamafufu

picked up a few books from the library this afternoon.  one of them was the mythical man-month by mr. fredrick brooks - an all time classic on the human elements of software engineering.  but wait a minute, do i not already have this book somewhere on my book shelf?  sure i do.  mine is a 1982 reprint of the 1975 first edition (the one on the left).  i had it for quite many years and had read it cover-to-cover.  the one on the right is the 1995 edition that i borrowed from the library today.

i read through the first two chapters this evening and was still amazed by the messages in this book which were written over 30 years ago.  the tar pits, the optimistic programmers, the interchangeable men and months, the gutless estimations, and the myth about adding more resources to a late project will improve the schedule - aren't they all sound so familiar even in the today's environment?

while technology has certainly improved and matured in a much more rapid rate since the 80s or even from a year or two ago,  the overall development of software engineering processes or disciplines has lagged behind.  come to think of it, is it really that much different from managing a software development project today comparing with 2, 5, 10 or even 20 years ago?  sure there are differences and improvements but certainly don't think they are that dramatic or far-reaching changes.  agile software development certainly is a good practice today but the concept existed in the 90s in a slightly different form or shape.  remember rapid application development (RAD) back in the PL/1 or C days?

today managers of software projects face many similar difficulties and challenges as described by mr. brooks in his book.  the ugly truth is it doesn't seem like we are much better off today after all these years.  so exactly what happened or what didn't happen?  did technology help or make the situation worse?  should we focus more on process improvement or maturity?   or does it all come down to the "human elements" of the whole software development ecosystem which include you, me and many others?

read this book or re-read this book.  would like to hear your view ...

it was a quiet sunday afternoon.  the snow had stopped and it was cold. my favoriate RTHK radio 2 was being streamed from the internet many timezones away.  i was enjoying a glass of wine with cheese and home-made candied walnut.  and i said to myself, what a perfect moment to think about software engineering demand management and project prioritization :-).

software engineering managers face many challenges today.  demand management is certainly one of them.   demand management can be loosely defined as a discipline or process that determines which software development projects should be commissioned and executed.  project prioritization is a complex process that involves many variables and factors such as business value, time, cost, risk, technical complexity, organizational capacity and many more.

demand management and project prioritization exist in most, if not all, software engineering organizations in different forms or shapes.  some are more formal and elaborate while others may be more informal and streamlined.  it all depends on the given business or organization environments and needs.  good demand management is important and needed because of the following reasons:

• there is always more projects to do than available resources.  if you are in a software engineering business and this doesn't happen to you, look for a new job.
• many software engineering projects fail or being canceled for many reasons.  while good demand management and project priortization doesn't guarantee success, it does help by asking and answering the following questions before projects can be started.  does the project have management support?  does the project bring clear value to the business?  does the project have high level scope and requirements?  does the project have high level time and cost assessed and understood?  does the project have support from all impacted organizations?
• one of the most visible measure of software engineering organization is success completion of projects that bring good vaule to the business both timely and cost effectively.  successful selection, prioritization and execution of projects play a large part in determining the overall success of the software engineering organization.

while this domain should not be a hard problem to solve plus there are many best and good practices on demand management processes to reference, consideration of your particulate environment and execution excellence are also some of the success factors.

more on this topic later.

may be i am just slow.

while i understand what pigs and chickens are referred to in the scrum project management method for agile software development, it did take me a while to really understand the analogy behind the story.  the story goes something like this:

A chicken and a pig were brainstorming...

Chicken: Let's start a restaurant!
Pig: What would we call it?
Chicken: Ham n' Eggs!
Pig: No thanks. I'd be committed, but you'd only be involved!

in scrum term pigs are committed to the project and accountable for the deliverables.  they get to talk in scrum meetings.  chickens are involved but not accountable for the deliverables so they don't get to talk in scrum meetings.  In other words, pigs sacrifice their lives to give beacon for the project, whereas chickens only have to give up their eggs.

while i welcome scrum or many other structured approaches to software engineering, i can't help but thinking scrum was developed by engineers for engineers.   there is nothing wrong with it as long as the process helps delivering good values to the business.  this reminds me of an infamous quote from mr. deng xiao ping.  it goes something like "不管白貓黑貓, 抓住老鼠是好貓" which translates to "It doesn't matter whether the cat is black or white as long as it catches mice".

regardless, from the culture that i was born and raised, i don't really want to be called pig or chicken but it is a total different topic.