Brian On Software

This is the third and last installment of lessons learned from reading “The Big Moo”.  The first lesson learned was about compromise and the second one was about being why being extreme is necessary sometimes.  This lesson is about knowing the importance of being proactive rather than reactive in a position of management or leadership.  It’s important, in order to be successful, to know how to trust and delegate work to people.  To be great at that, you must treat your co-workers/employees first of all as humans, and also take time to know them on personal/professional level.  What do they like to work on?  What are they passionate about in their job?  What motivates them to spend their energy, intelligence and experience to help your organization achieve its goals and drive its strategy?  Discovering the values behind these variables will make you more remarkable in your organization.  Furthermore, this lesson teaches you to stop being a fireman and instead be an innovator.  You have too much smarts to indulge your time in putting out fire caused by other people.  It’s important to realize that you simply can’t handle every single situation at work.  Sometimes when there’s just too many fires to put out, the best thing to do is build some brick walls to isolate your from them, but also to help you set a path that will guide you to success.  That being said, I present you the last essay for this lesson.  This one is entitled “Juggling Is Not What You Think” and (yep, you’ve guess it) and its author is unknown.

Juggling Is Not What You Think It Is

“Sometimes, I teach juggling classes.  Everyone wants to get the learning process of how to juggle three balls over with as quickly as he can.  The universal approach people take is to devote all their attention and effort at catching the calls.  They just throw ‘em up and rush around trying to catch them.  Extraordinary efforts are justified to catch the balls, because after all, if a ball hits the ground, you’ve failed.  The nascent juggler expects that with enough practice, they’ll get really good at catching balls.”

“Lots of your peers think that they’re good at juggling.  They rush this way and that, dealing with emergencies, handling multiple priorities, and never letting anything fall through the cracks.”

“But that’s not juggling.  That’s rushing around like a madman.  Let them be good at that.  There are plenty of people out there who are great at rushing about and handling emergencies, and frankly, they don’t need your help.”

“It turns out that juggling is about throwing, not catching. The way to learn how to juggle is not to focus obsessively on not dropping a ball.  No, the way to get good at juggling is to focus on your throw instead.”

“If you are good at throwing, the catching will take care of itself.”

“Once you’ve got three or four or five projects in the air at work, no amount of rushing around is going to keep them from crashing to the ground.  No amount of effort can help you catch the misthrown balls.  It’s physically impossible.”

“On the other hand, if your balls are well thrown, the catching is effortless.”

“That’s part of the secret of becoming remarkable.  Don’t spend any time at all worrying about catching.  Let your co-workers do that.  Instead, become the best thrower there ever was.  If you become good at throwing, you’ll find that you’re irreplaceable.  Organizations need really good throwers.”

This is the second installment of lessons learned from reading “The Big Moo“.  It goes inline with the first lesson learned about compromises.  This time, we’re talking about being “extreme” in the sense that you shouldn’t accept status quo if there’s no value, no growth and no opportunities associated with a given situation that you’re involved in.  I hope that the following essay taken directly from the book will inspire you to be different, to be realistic, but more importantly to be remarkable in taking sound actions to push the barrier for excellence a bit higher even when the crowd shouts differently.  It’s important that you realize when “enough is enough” and realize that your integrity and credibility is on the line every time you’re doing something that violates your set of values and principles.  Here is the full text from (once again) an unknown author:

They Say I’m Extreme

They say I’m extreme.
I say I’m a realist.

They say I demand too much.
I say they accept mediocrity and continuous improvement too readily.

They say, “We can’t handle this much change.”
I say, “Your job and career are in jeopardy; what other options do you have?”

They say, “What’s wrong with a ‘good product’?”
I say, “Wal-Mart or China or both are about to eat your lunch.  Why can’t you provide instead a fabulous experience?”

They say, “Take a deep breath.  Be calm.”
I say, “Tell it to Wal-Mart.  Tell it to China.  Tell it to India.  Tell it to Dell.  Tell it to Microsoft.”

They say the Web is a useful tool.
I say the Web changes everything.  Now.

They say, “We need an initiative.”
I say, “We need a dream.  And dreamers.”

They say great design is “nice”.
I say great design is necessary.

They say, “Effective governance is important.”
I say bold, brash boards that are representative of the market served – more than a token woman or two and an empty seat for the “forthcoming Hispanic” – are an imperative.  Now.

They say, “Plan it.”
I say, “Do it”.

They say, “We need more steady, loyal employees.”
I say, “We need more ‘freaks’ who routinely tell those in charge to take a flying leap…before it’s too late.”

They say, “We need Good People.”
I say, “We need Quirky Talent.”

They say, “We like people who, with steely determination, say, ‘I can make it better’.”
I say, “I love people who, with a certain maniacal gleam in their eye, perhaps even a giggle, say, ‘I can turn the world upside down.  Watch me!’”

They say, “Sure, we need change.”
I say we need revolution now.

They say, “Fast follower.”
I say, “Battered and bruised leader.”

They say, “Conglomerate and imitate!”
I say, “Create and innovate!”

They say, “Market share.”
I say, “Market creation.”

They say, “Improve and maintain.”
I say, “Destroy and reimagine.”

They say, “Normal.”
I say, “Weird.”

They say, “Happy balance.”
I say, “Creative tension.”

They say they favor a “team that works and lives in harmony.”
I say, “Give me a raucous brawl among the most creative people imaginable.”

They say, “Peace, brother.”
I say, “Bruise my feelings.  Flatten my ego.  Save my job.”

They say, “Basic black.”
I say, “Technicolor rules!”

They say, “We need happy customers.”
I say, “Give me pushy, needy, nasty, provocative customers.”

They say, “We seek Harvard M.B.A.s.”
I say, “I seek certificate-free ‘Ph.D.S’ from the School of Hard Knocks.”

They say they want recruits with “spotless records.”
I say, “the spots are what matter most.”

They say, “Integrity is important.”
I say, “Tell the unvarnished truth, all the time…or take a hike.”

They say diversity is a “good thing.”
I say diversity is breath of fresh, creative air – absolutely necessary for economic salvation in perilous times.

They say it’s “daunting.”
I say it’s “a hoot.”

They say, “Zero defects.”
I say, “A day without a screwup or two is a day pissed away.”

They say, “Think about it.”
I say, “Try it.”

They say, “Plan it.”
I say, “Test it.”

They say, “Radical change takes a decade.”
I say, “Radical change takes a minute.”

They say, “Times are changing.”
I say, “Everything has already changed.  Tomorrow is the first day of your revolution…or you’re toast.”

They say, “We can’t all be revolutionaries.”
I say, “Why not?”

They say, “We can’t all be a brand.”
I say, “Why not?”

They say this is just a rant.
I say this is just reality.

As promised in my review of The Big Moo, I will share with you three different lessons learned from reading the book.  The first lesson deals with compromise.  The field of software development is full of stories about products being bloated with unwanted or unnecessary features, costs overrun, late delivery dates, etc.  One reason that explains the cause of this is the lack of courage (that’s right, the same courage that Kent Beck preaches in Extreme Programming) from developers, analysts, managers or any serious project stakeholder to say “Hey, wait a minute!  I seriously we should think about this before we go on!” for example.  Lacking courage in such situations can make place for compromise to settle in and take more space than it should be allowed.  Once compromise is leading the project, the product will suffer, your team will suffer, your organization will suffer, your customer(s) will suffer, and this profession will suffer.  So why should you keep an eagle eye on compromise?  How can you avoid it?  Why should you avoid it?  This first lesson is well told in the essay title “The Problem With Compromise“.

Here’s the full text of this essay (author unknown):

The Problem With Compromise

“Any organization with more than one person in it is a place of compromise.  If you want to get something done, a project okayed, a budget approved, a product sold, you’re going to have to compromise.”

“Most of the time, it seems as though half is better than none.  If you refuse to compromise, nothing happens.  And this desire to make it happen explains why so many things are mediocre.  It tells us why it’s so hard to make something remarkable, and why the remarkable succeeds so easily.  Because everything is a compromise, everything is sort of mediocre, isn’t it?”

“The wireless Internet access at the Denver airport has compromise written all over it.  I’m sure that when it was first designed (probably by a lone engineer in a cubicle), it was simple and fast and easy to use.  Today, however, it takes at least a dozen clicks to get started.  You need to enter a username and ID not once, but twice.  And your ID must be at least eight characters long and include numbers and a special character like $, %, or #.  So, something like “$3eVh!” is not secure enough because it’s too short.  Huh?  This isn’t your credit rating you’re protecting…it’s just the right to spend nine dollars and go online.”

“At every step along the way, each compromise to the sign-on system seemed reasonable.  At each step, the evolution of the design was simple: Either the project manager had to go along with the needs of this or that person (and the boss) or risk having the project canceled.  What would you do?  All those compromises may have made each person happy, but the final product was something that absolutely no one liked.”

“The first step to fighting back is understanding how compromise corrupts the things you’re so busy building.  More often than not, half is actually worse than none.  More often than not, you’re better off doing nothing than shipping something that is just average.  The project manager in Denver should have just stopped the project and let the chorus of complaints from passengers sink in to make the case for doing things the right way from the start.”

“Twenty years ago, Japanese car companies solved their quality control problem using a technique called Kanban.  Instead of following the American technique of having plenty of spare parts on the assembly line (workers were told to just discard a screw if it didn’t fit right), the Japanese adopted a fundamentally different strategy.  They kept only one necessary part at a time on the assembly line.  If the part wasn’t perfect, the entire assembly line stopped until a new part arrived.”

“The Americans said that this was insane.  Everyone knew that keeping the assembly line moving was the only way to make a car efficiently.  If a finished car wasn’t good enough, then you fixed it after it was assembled.”

“What Toyota and Honda understood was that the act of stopping the assembly line would send a powerful signal to every worker and to every supplier.  Sure enough, the line didn’t have to stop very often.  Every part improved in quality, because no one wanted to be responsible for shutting the operation down.  As a result, better parts improved every car as well.  With Kanban, very few cars left the assembly line in need of later reworking.  It turned out to be cheaper and faster to build cars right the first time than it was to fix them later.”

“You might try the same thing in your organization.  Refuse to compromise.  See what happens.  For a while, the assembly line will slow down or even stop.  Things won’t ship, products will get stuck in development.  And then a funny thing will happen: People will begin to understand that compromising the product just to keep the system working is stupid.  The only reason the system exists is so that you can make the things you make, right?  So if the system is demeaning your work, change the system.”

What do you think?  Are you currently in such a situation where compromise has settled in your project team?  What did you do to get out of the situation and prevent it from repeating itself?  Your comments are encouraged for this first lesson learned.

Every Sunday morning at our church, an usher is always ready to welcome members and guests with a smile and also a weekly newsletter in its hand for us.  I like reading it during the "weekly announcements" part of the service because there’s always a funny joke and also inspiring words.  I want to share with you what my pastor wrote in this week’s newsletter.  I hope that it’ll be a word of encouragement and also a blessing to you for this week.

"As the massive Boeing 777 jet accelerated down the runway, then lifted into the air, I was again in awe at the magnificent power that would lift such immense weight to a cruising altitude of more than 43,000 feet.   As the plane entered an area of turbulence and the giant machine was tossed about as though it weighed nothing, I was reminded of the tremendous, awe-inspiring force of the One who is the source of all power. 

We witness God’s power in so many areas and ways as we journey through this world: in the roaring of mighty waterfalls, the glories of a sunrise, the churning of the seas, the birth of our babies.  We witness His ultimate power in our own lives — in our own personal experiences as we come to know Him as the One who cares for and loves us individually and unconditionally. 

He knows and cares about every difficulty we face and each heartbreak we suffer. It is difficult to understand how such a powerful God, who rules the universe, would care for us on a personal basis.  We must come to understand that God does not allow His work of keeping all things in the universe in its proper place to divert His attention from us personally, nor does it interfere with His working in our individual lives!"

Amen.

My wife sent me this email today.  I thought that it might be a good idea to share it.  Here goes.

God first separated the salt water from the fresh, made dry land, planted a garden, made animals and fish… all before making a human. He made and provided what we’d need before we were born. These are best & more powerful when eaten raw. We’re such slow learners…

God left us a great clue as to what foods help what part of our body!

God’s Pharmacy! Amazing!

A sliced Carrot looks like the human eye. The pupil, iris and radiating lines look just like the human eye… and YES, science now shows carrots greatly enhance blood flow to and function of the eyes.

A Tomato has four chambers and is red. The heart has four chambers and is red. All of the research shows tomatoes are loaded with lycopine and are indeed pure heart and blood food.

Grapes hang in a cluster that has the shape of the heart. Each grape looks like a blood cell and all of the research today shows grapes are also profound heart and blood vitalizing food.

A Walnut looks like a little brain, a left and right hemisphere, upper cerebrums and lower cerebellums. Even the wrinkles or folds on the nut are just like the neo-cortex. We now know walnuts help develop more than three (3) dozen neuron-transmitters for brain function.

Kidney Beans actually heal and help maintain kidney function and yes, they look exactly like the human kidneys.

Celery, Bok Choy, Rhubarb and many more look just like bones. These foods specifically target bone strength. Bones are 23% sodium and these foods are 23% sodium. If you don’t have enough sodium in your diet, the body pulls it from the bones, thus making them weak. These foods replenish the skeletal needs of the body.

Avocadoes, Eggplant and Pears target the health and function of the womb and cervix of the female – they look just like these organs. Today’s research shows that when a woman eats one avocado a week, it balances hormones, sheds unwanted birth weight, and prevents cervical cancers. And how profound is this? It takes exactly nine (9) months to grow an avocado from blossom to ripened fruit. There are over 14,000 photolytic chemical constituents of nutrition in each one of these foods (modern science has only studied and named about 141 of them).

Figs are full of seeds and hang in twos when they grow. Figs increase the mobility of male sperm and increase the numbers of Sperm as well to overcome male sterility.

Sweet Potatoes look like the pancreas and actually balance the glycemic index of diabetics.

Olives assist the health and function of the ovaries

Oranges, Grapefruits, and other Citrus fruits look just like the mammary glands of the female and actually assist the health of the breasts and the movement of lymph in and out of the breasts.

Onions look like the body’s cells. Today’s research shows onions help clear waste materials from all of the body cells. They even produce tears which wash the epithelial layers of the eyes. A working companion, Garlic, also helps eliminate waste materials and dangerous free radicals from the body.

In last week’s Bible study at my church, a scripture came into my mind that I felt like sharing with you.  I think it fits well with our profession in software development.  But just before I jump into it, I’ll tell you the reason that pushed me to write this post.  If you’ve been involved in a software project for some time you’ve probably noticed that it’s a pretty stressful profession.  Whether you’re a lone wolf or part of a team, the goal is the same: delivering a product or a service to a client.  The product can be either a component, a system, API documentation, tests, samples, installers, etc.  The service can be playing the role of an auditor or a consultant inside an organization.  The client in both instances often share the same characteristics: they don’t often know what they want or expect from the product or service, and  they somehow seem to be determined on a date as if saying "I don’t know exactly what I want, but I definitively know when I want it".  In my little head, this just doesn’t make sense.  This reminds me of an instance where one of our managers sent an email to the team with the deliverables for the next iteration.  It pretty much went like this:

Manager: All right Team.  Here are your next deliverables.  Please tell me immediately if you’ll have a problem meeting these dates:

=> Joe, you will be working with Susan on component A.  This is due on August 25.

=> Alice, you will be responsible for component B and C.  You will also produce the documentation.  This is also due on August 25.

The problem with the last scenario was that no one knew what components A, B and C were suppose to be or do.  There was no functional design whatsoever.  The only thing that was certain was the date.  And even then, we had no idea how that date came to be.  And we had to agree on whether we were able to deliver unknown variables in a definitive point in time.  That’s like a chief builder telling his subordinates to build a bridge (a product) but without fully understanding or knowing what’s at stake (the specifications), except for that date…that magic date where nor science nor common sense can help us to derive its reason.  Sad…very sad.

I remember once reading an article which described the work conditions and environment of the Window NT 4.0 team at Microsoft while working towards that operating system.  Apparently, it was so bad that some individuals ended up developing health problems, other went through divorce because their project was so demanding that they had to sleep over at the office on many occasions, some decided to quit and completely change professions, etc.  My gosh…now that’s sad too.  I mean who’s actually using Windows NT 4.0 nowadays?  No doubt Windows NT 4.0 served as the basis of the Windows operating systems that we know today (XP, Vista, Server 2003, etc.), but was it really worth the health and lives of those human beings?  I certainly don’t think so.  I don’t doubt that there was some poor management decisions and weak estimations that went with the project, but that doesn’t change the fact that some lives were ruined by it.  Twelve years later since the release of that product, information technology as we know it has changed dramatically and the way that software is being built has morphed into a more sophisticated discipline, but it still seems that team members are stressing more than before.  It seems like their health and their lives are still on the brink of destruction.

In my experience, I’ve learned long ago not to stress for anything in life.  When I was 15 years old, I was diagnosed with a bleeding ulcerative colitis.  I still have it inside of me and if I stress too much, I’m quickly reminded to calm down.  One reason why I certainly don’t stress in software development is twofold.  First of all, software development is a passion.  Fred Brooks said it well in The Mythical Man-Month:

Why is programming fun?  What delights may it practitioner expect as his reward?

1. First is the sheer joy of making things.  As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design.  I think this delight must be an image of God’s delight in making things, a delight shown in the distinctness and newness of each leaf and each snowflake.
2. Second is the pleasure of making things that are useful to other people [...].
3. Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning [...].
4. Fourth is the joy of always learning, which springs from the nonrepeating nature of the task [...].
5. Finally, there is the delight of working in such a tractable medium.  The programmer, like the poet, works only slightly removed from pure though-stuff.  He builds his castles in the air, from air, creating by exertion of the imagination [...].

Second of all, software products tend to have a very short life.  I don’t have the exact numbers, but I can confidently say that systems are changed or rebuilt every 36-48 months in average.  So that means that the system you worked on so hard for so many hours, that system that made your body ache because of those long sitting periods, that system that made you swear multiple times, that system that built and destroyed human relationships, that system that made you doubt whether or not you were made for this profession, that system that replaced your family…where is that system now?  Was it really worth your health and your life?

The scripture that was in my heart since last week can be found in the Book of Ecclesiastes 2:18-26.  It’s a wake up call that really hits hard because it opens our eyes and helps us to realize that there is more to life than sacrificing our health, our lives and our soul to meeting a stupid date and building something that’s so temporary that it is sometimes not worth our intelligence and effort.  I’ll end the post with the scripture in two versions to help you better understand what the writer is saying.

Ecclesiastes 2:18-26 (The Message)

18-19 And I hated everything I’d accomplished and accumulated on this earth. I can’t take it with me—no, I have to leave it to whoever comes after me. Whether they’re worthy or worthless—and who’s to tell?—they’ll take over the earthly results of my intense thinking and hard work. Smoke.

20-23 That’s when I called it quits, gave up on anything that could be hoped for on this earth. What’s the point of working your fingers to the bone if you hand over what you worked for to someone who never lifted a finger for it? Smoke, that’s what it is. A bad business from start to finish. So what do you get from a life of hard labor? Pain and grief from dawn to dusk. Never a decent night’s rest. Nothing but smoke.

24-26 The best you can do with your life is have a good time and get by the best you can. The way I see it, that’s it—divine fate. Whether we feast or fast, it’s up to God. God may give wisdom and knowledge and joy to his favorites, but sinners are assigned a life of hard labor, and end up turning their wages over to God’s favorites. Nothing but smoke—and spitting into the wind.

Ecclesiastes 2:18-26 (New Living Translation)

The Futility of Work
18 I came to hate all my hard work here on earth, for I must leave to others everything I have earned. 19 And who can tell whether my successors will be wise or foolish? Yet they will control everything I have gained by my skill and hard work under the sun. How meaningless! 20 So I gave up in despair, questioning the value of all my hard work in this world.

21 Some people work wisely with knowledge and skill, then must leave the fruit of their efforts to someone who hasn’t worked for it. This, too, is meaningless, a great tragedy. 22 So what do people get in this life for all their hard work and anxiety? 23 Their days of labor are filled with pain and grief; even at night their minds cannot rest. It is all meaningless.

24 So I decided there is nothing better than to enjoy food and drink and to find satisfaction in work. Then I realized that these pleasures are from the hand of God. 25 For who can eat or enjoy anything apart from him?[a] 26 God gives wisdom, knowledge, and joy to those who please him. But if a sinner becomes wealthy, God takes the wealth away and gives it to those who please him. This, too, is meaningless—like chasing the wind.

By the way, if you’re looking for a better way to estimate your software projects, please by all means (legally of course…) read Steve McConnell’s book on software estimation: Software Estimation: Demystifying the Black Art from Microsoft Press.  In my opinion, bad estimation is the major source of project failures and broken lives in software development.

I was reading an interesting article in The Globe And Mail this week about how more and more managers are getting laid off their positions in the corporation due to the economic situation we’re currently in.  This affliction doesn’t affect the IT industry alone; it’s striking almost every companies in every sector in every country.  In order for workers in management to increase their stakes at keeping their current job or getting more attention for further opportunities, there are a few key points that should be considered.

In the Management Survivor Guide, Monika Morrow of Right Management points out a few ideas to make yourself more profitable and valuable.  Since this article pretty much goes in hands with my post on how to become a more valuable software professional, I thought that Morrow’s article would be a good complement to it.  So, without further a due, here’s the “Management survivor guide” which aside from targeting managers can actually benefit software professionals alike.

The Management Survivor Guide by Monika Morrow of Right Management:

• Position Yourself
  Scan the organization and the industry and make sure you are involved in an area that is hot and growing.

• Think Strategically
  Discuss the organization’s strategy with senior executives and point out how you fit their coming needs.

• Build Your Skills
  Don’t wait until the company offers training – stay on top of tech and management trends with courses and online learning.  (Check out my post on personal and professional development through reading for another take on this one)

• Be Multitalented
  If two operations are being combined, a manager who knows both parts will be more valuable than one who has experience in only one part.

• Get Advice
  Ask trusted colleagues or a coach to critique your management style and experience for areas where you might need development.

• Market Yourself
  Develop and tell stories of your successes.  You want to be known as the problem solver too valuable to let go.  (I highly recommend reading Jean-Paul Boodhoo’s blog to get an example of this point.  JP clearly nails this one as he constantly shares his successes publicly on his blog)

• Be Seen As An Authority
  Offer to mentor, organize training and speak at industry functions.

• Don’t Rush
  If it becomes clear you are facing the axe, don’t just take the first job that comes along without assessing whether it meets your interests and long-term goals. (This one is very important in my opinion.  Don’t waste your time on a job that isn’t compatible with your values and dreams.  If you are in such a situation, I also recommend you to read The Dip by Seth Godin.  Seth gives you some key points to consider in such situations)

Boy was I late for this one!  In case your academic institution lacks a MSDNAA account, Microsoft has launched DreamSpark, a program dedicated for students to get access to various .NET development tools like Visual Studio 2008 Professional Edition, Microsoft Expression Studio, Windows Server 2003 Standard Edition, SQL Server 2005 Developer Edition, etc. for free!  The only caveat is that this program is only valid in the following countries:

• United States
• United Kingdom
• Canada
• China
• Germany
• France
• Finland
• Spain
• Sweden
• Switzerland
• Belgium

It sucks that Australia, India and Russia aren’t there also, but hopefully they’ll be added before the end of the year (or before you graduate!).

There’s also a FAQ page available that might answer some of your typical questions.

Now you have a good excuse to put the books down and play with LINQ for a while

As you may have probably heard, Bill Gates will soon step down from Microsoft and step up to focus more of his energy toward his philanthropic and charity organization, the Bill & Melinda Gates Foundation.

CNNMoney has published quite a nice set of new articles about the legacy of Microsoft and Bill Gates.  Read more on “Microsoft Without Gates”.

In Ten Simple Tips To Become A Valuable Software Professional, I listed “reading literature on various aspects of software engineering” at the top of the list. As you may probably know, our profession is pretty young compared to the other more traditional engineering fields as building engineering, electrical engineering and mechanical engineering. According to history, the term software engineering was popularized by F.L. Bauer during NATO Software Engineering Conference in 1968.

Exactly 40 years have passed since that conference was held in Germany and practitioners are still saying that software engineering is a pretty immature field and, unfortunately, displays a bad image as one of the major engineering branches. In the first page of the now popularized 1995 software engineering CHAOS Report from The Standish Group, a reason is given which supports the previous affirmation:

One of the biggest reasons bridges come in on-time, on-budget and do not fall down is because of the extreme detail of design. The design is frozen and the contractor has little flexibility in changing the specifications.

However, in today’s fast moving business environment, a frozen design does not accommodate changes in the business practices. Therefore a more flexible model must be used. This could be and has been used as a rationale for development failure. But there is another difference between software failures and bridge failures, beside 3,000 years of experience. When a bridge falls down, it is investigated and a report is written on the cause of the failure. This is not so in the computer industry where failures are covered up, ignored, and/or rationalized. As a result, we keep making the same mistakes over and over again.

There’s no doubt that that statement is still true: today’s software systems are much more complex to design and build than ever before. But then again, just like Jeff Atwood so properly stated, God didn’t invent x86. The laws governing physics in our planet are perfect. I can not say the same for the laws governing software engineering. I doubt whether we are going to achieve success from projects to projects unless we take time for ways to improve the way we design and deliver software. Nowadays we have to take into consideration many factors which comprises a software project:

• Constantly evolving technologies which we have to familiarize ourselves with (from COM/COM+ to .NET for example)
• Constantly changing requirements from stakeholders who seldom have a clue of what they want, even less of what they need in the first few iterations (typical)
• Pressure from the marketplace to constantly ship early, which increases the chance for bugs to make their way in the code (which proves Guy Kawasaki’s thought that in the software market, we ship and then we test)
• Dealing with social and cultural factors as more teams are composed of different people from around the world, each with their own unique personality, belief system, education and “professional ladder system”
• Evolving hardware that our software needs to support (by hardware, I don’t mean just computers or mobile devices, but think about automobiles, airplanes, autonomous unmanned vehicles (AUVs), medical devices, etc.)
• Familiarizing ourselves with heterogeneous software processes and methodologies when a company merges with another one (typical too).

My guess is that it will take many years, if not decades, before we see any improvement in each of those points above. And if Brook’s “Silver Bullet” theorem turns out to be a real prophecy (it hasn’t failed so far), then we better hold on to our keyboards and continue to find improvements to these problems, because just like our planet’s environment, our field is going to become a dangerous zone to live/work in…unless we do something about it. And you know what? There are many realistic solutions to such problems, and lots of them are waiting to be unfolded by people like you and me. I strongly believe that such solutions are being found in books and other literature in which professional individuals took some time in their lives to explain the problems and provide solutions to those problems in order to make our profession a better work environment for all. Not everything in software engineering is 100% about .NET, Java, TDD, Web application, SOA, software patterns, testing or software quality. In fact, according to Wikipedia’s definition on software engineering:

The discipline of software engineering includes knowledge, tools, and methods for software requirements, software design, software construction, software testing, and software maintenance tasks.

Software engineering is related to the disciplines of computer science, computer engineering, management, mathematics, project management, quality management, software ergonomics, and systems engineering.

The same is true for the other branches in engineering: not everything revolves around tools and technologies. In one of my engineering course, a professor once told us that engineers praise the Pareto principle (also known as the 80-20 rule). One instance of that rule is that for any engineering profession, in most cases, 80% of a project revolves around human interactions and only 20% is concerned about tools and technologies. Some even think that the actual rapport is 90-10. Nevertheless, we can agree that even in software engineering, human interactions and relationships have the upper hand in most software projects.

Going back again to the CHAOS report, the researchers discovered that three major reasons that a project will succeed are:

User involvement

Executive management support

Clear statement of requirements

According to them, “there are other success criteria, but with these three elements in place, the chances of success are much greater. Without them, chance of failure increases dramatically“. The following table shows what survey participants answered when asked about the factors that contribute the most to the success of a project:

These same survey participants were also asked about the factors that cause projects to be challenged.

Figure 1. My technology-oriented books collection (.NET, Java, PHP, Perl, OO, etc.)
 

All these results show that human-based decisions and interactions are much more important than knowledge of a technology when determining the success of a project. And as such, I urge software professionals to read books and literature beyond those that are technology-focused. Reading books about .NET, Java, EJBs, or other technology-focused subject is good for your current project or job (short-term) but not that great for your professional ladder (long-term) because technology changes so drastically in such a short time that we have to keep up with the new bits and bytes, whereas reading materials that focus on principles tend to be technology-independent and longer lasting.

That being said, I recommend books that deal about leadership, personal development, teamwork, business, economics, different cultures from around the world, etc. My favorite book of all is the Bible because it is a collection of 66 books that touch base with all those human-oriented subjects. A library of one book…simply amazing! But there are also other books which I highly recommend if you’re serious about becoming a better developer and more solid software professional. Figure 1 shows the technology-oriented books in my library which I have read and have been a great help in my projects…but I haven’t developed with COM/COM+ in over 5 years! I don’t even remember the last time I compiled a C++ application. I keep those books mostly to show novice programmers what was the world of development before .NET, but other than that, I don’t have much use for them. On the other hand, Figure 2 shows the books in my library which deal with human interaction and personal development. These books I have read and re-read many times. They have helped me in the job and outside the job as well. They have helped me to grow as both a professional and as an individual. Rare is a software project that is being built by just one single individual. Even open source software project involve multicultural individuals from all around the world. Trust me: technology is not the primary factor that will bring success to any software project. It will never be. People is the factor that makes the difference whether a project will succeed or not. Software is built by people and for people. Even operating system software and real-time software aren’t primarily built for hardware…they’re built for people. Knowing how to deal with people, even outside your organization, is the cornerstone of any software project independently of its criticality and scope. So next time you’re visiting Amazon, think twice before buying another popular .NET, Ruby or Java book and rather consider purchasing a book that will help you grow as an individual and make you a much better software professional.  

Figure 2. My human-centric books (personal development, business, leadership, etc.)

As you can see from both pictures above, my human-centric books only require one shelf, compared to two shelves for my technology-centric book (I might even need a third shelf as I’m starting to stack one upon another). You don’t need as much of these human-centric books. Just a handful is plenty enough. My favorite authors of such literature are Seth Godin, Guy Kawasaki, John Maxwell and Malcolm Gladwell. Three out of four of these authors maintain an active blog which you can access publicly at no cost.

But please, dear reader, don’t misunderstand me on books focused entirely on technology. I’m not saying they’re not worth it, quite on the contrary. They are excellent for reference on a very specific topic, but their scope is very narrow. There are two excellent resources which I recommend to software engineers who are looking for better ways to improve themselves and their profession:

• The Guide to the Software Engineering Body of Knowledge

From Wikipedia:

The software engineering body of knowledge is an all-inclusive term that describes the sum of knowledge within the profession of software engineering. Since it is usually not possible to put the full body of knowledge of even an emerging discipline, such as software engineering, into a single document, there is a need for a Guide to the Software Engineering Body of Knowledge. This Guide will seek to identify and describe that subset of the body of knowledge that is generally accepted, even though software engineers must be knowledgeable not only in software engineering, but also, of course, in other related disciplines.

• The ACM/IEEE’s Software Engineering Code of Ethics and Professional Practice

The Code contains eight Principles related to the behavior of and decisions made by professional software engineers, including practitioners, educators, managers, supervisors and policy makers, as well as trainees and students of the profession. The Principles identify the ethically responsible relationships in which individuals, groups, and organizations participate and the primary obligations within these relationships. The Clauses of each Principle are illustrations of some of the obligations included in these relationships. These obligations are founded in the software engineer’s humanity, in special care owed to people affected by the work of software engineers, and the unique elements of the practice of software engineering. The Code prescribes these as obligations of anyone claiming to be or aspiring to be a software engineer.

I’ll end this post with a powerful statement from the CHAOS report as they conclude their report:

There is one final aspect to be considered in any degree of project failure. All success is rooted in either luck or failure. If you begin with luck, you learn nothing but arrogance. However, if you begin with failure and learn to evaluate it, you also learn to succeed. Failure begets knowledge. Out of knowledge you gain wisdom, and it is with wisdom that you can become truly successful.

That wisdom you also gain it by learning from each other: from your team members, your customers, your managers, your employees, and others. An easy and quick access to such wisdom is also in taking some time in reading human-centric books over technology-focused books. It worked for me…no doubt it’ll work for you.

A co-worker forwarded us a link to a tourism site about Montreal.  It’s the very first time I see this kind of aerial/ground scenery shot in a film. 

If you have two minutes to spear and would like to see more of Montreal (from the sky to the streets), check out http://www.tourisme-montreal.org/.

Every Sunday morning, we are greeted by an usher at church who hands out a weekly news bulletin with various activities, birthdays reminders, words from the pastor and other stuff related to our little church.  A while back, I read something I promised myself I would share on my blog.  I should’ve written this two weeks ago, but I guess there’s never a wrong time to do something good, so here goes.  This one was a real reminder of God’s perfect example to follow as we journey in our lives.  It’s ten simple principles (or self-promises) that can positively affect your life and other people’s lives as well.  I hope you will share them and reveal them in your life.  God bless.

1. Today I will not strike back…

If someone is rude, if someone is impatient, if someone is unkind, I will not respond in a like manner.

2. Today I will ask God to bless my ‘enemy’…

If I come across someone who treats me harshly or unfairly, I will quietly ask God to bless that individual.  I understand ‘enemy’ could be a family member, neighbor, co-worker or stranger.

3. Today I will be careful about what I say…

I will carefully choose and guard my words being certain that I do not spread gossip.

4. Today I will go the extra mile…

I will find ways to help share the burden of another person.

5. Today I will forgive…

I will forgive any hurts or injuries that come my way.

6. Today I will do something kind for someone (but I will do it in secret…)

I will reach out anonymously and bless the life of another.

7. Today I will treat others the way I wish to be treated…

I will practice the golden rule.  "Do unto others as I would have them do unto me"- with EVERYONE I encounter.

8. Today I will raise the spirits of someone who is discouraged…

My smile, my words, my expression of support, can make the difference to someone who is wrestling with life.

9. Today I will nurture my body…

I will not over eat…I will eat healthy…I will thank God for my body.

10. Today I will grow spiritually…

I will spend a little more time in prayer and bible reading today.  I will begin reading something spiritual or inspirational; I will find a quiet place and listen to God’s voice.