Frederick P. Brooks

He was Corporate Project Manager for the System/360, including development of the System/360 computer family hardware and the decision to switch computer byte size from 6 to 8 bits.

His best-known books are

• The Mythical Man-Month (1975, 1995); 
• Computer Architecture: Concepts and Evolution (with G.A. Blaauw, 1997); and 
• The Design of Design (2010).

 Dr. Brooks has received the National Medal of Technology, the A.M. Turing award of the ACM, the Bower Award and Prize of the Franklin Institute, the John von Neumann Medal of the IEEE, and others. He is a member of the U.S. National Academies of Engineering and of Science, the American Academy of Arts and Sciences, the Royal Academy of Engineering (U.K.) and of the Royal Netherlands Academy of Arts and Sciences.

The Mythical Man-Month

Few books on software project management have been as influential and timeless as The Mythical Man-Month. With a blend of software engineering facts and thought-provoking opinions, Fred Brooks offers insight for anyone managing complex projects. These essays draw from his experience as project manager for the IBM System/360 computer family and then for OS/360, its massive software system. 20 years after the initial publication of his book, Brooks has revisited his original ideas in a new version.

1. a crisp condensation of all the propositions asserted in the original book, including Brooks' central argument in The Mythical Man-Month: that large programming projects suffer management problems different from small ones due to the division of labor; that the conceptual integrity of the product is therefore critical; and that it is difficult but possible to achieve this unity; 
2. Brooks' view of these propositions a generation later; 
3. a reprint of his classic 1986 paper "No Silver Bullet";[printed in Computer mag April 1987]
   "Essence and Accidents of SW Engineering"
4. today's thoughts on the 1986 assertion, "There will be no silver bullet within ten years."

Tom DeMarco

Bell Lab
ESS-1 SW Engineer, from an electronic background.

What's the matter with you software people?

" ... everything we were doing had the unstated goal of moving the hard stuff out of the hardware into the software."

Founder of the "Atlantic Systems Guild"

Early work on SW design metrics now no longer supported ! 

Now apply “You can’t control what you can’t measure” to the teenager. Most things that really matter—honor, dignity, discipline, personality, grace under pressure, values, ethics, resourcefulness, loyalty, humor, kindness—aren’t measurable.  You must steer your child as best you can without much metric feedback. It’s hard, but then parenting is hard. You get a little bit of measurement in the form of school grades, and you’re grateful for it. But you also know that your child’s math grade is a better indicator of achievement than his Spanish grade, because math understanding is easier to measure. And his “grade” in comportment is much more likely to tell you something about the teacher than about the child.

.... So far, I’ve mostly discussed software engineering’s metric component. How about the rest? I’m gradually coming to the conclusion that software engineering is an idea whose time has come and gone. I still believe it makes excellent sense to engineer software. But that isn’t exactly what software engineering has come to mean. The term encompasses a specific set of disciplines including defined process, inspections and walkthroughs, requirements engineering, traceability matrices, metrics, precise quality control, rigorous planning and tracking, and coding and documentation standards. All these strive for consistency of practice and predictability.

Consistency and predictability are still desirable, but they haven’t ever been the most important things. For the past 40 years, for example, we’ve tortured ourselves over our inability to finish a software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business. We’ve been rather successful at transformation, often while operating outside our control envelope. Software development is and always will be somewhat experimental. The actual software construction isn’t necessarily experimental, but its conception is. And this is where our focus ought to be. It’s where our focus always ought to have been.

Classic book :   Peopleware 

February 1, 1999

Demarco and Lister demonstrate that the major issues of software development are human, not technical. Their answers aren't easy--just incredibly successful.

Other publications :

    1979. Structured Analysis and System Specification. Prentice Hall, ISBN 0138543801
    1986. Controlling Software Projects: Management, Measurement, and Estimates. Prentice Hall,
           ISBN 0131717111
    1987. Peopleware: Productive Projects and Teams. With Timothy Lister. Dorset House.
           ISBN 978-0932633439
    1997. The Deadline: A Novel About Project Management. Dorset House.
    2001. Slack, Getting Past Burnout, Busywork, and the Myth of Total Efficiency.
    2003. Waltzing with Bears: Managing Risk on Software Projects.
           With Tim Lister. Dorset House in March, 2003.
    2008. Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior.
           With Peter Hruschka, Tim Lister, Suzanne Robertson, James Robertson, Steve McMenamin.
           ISBN 978-0932633675

    2009. "Software Engineering: An Idea Whose Time Has Come and Gone?".
           IEEE Software, Viewpoints. July/August 2009. pages 94–95.

Grady Booch: On Archtecture

Grady Booch

best known for developing the Unified Modeling Language with Ivar Jacobson and James Rumbaugh.

Grady is recognized internationally for his innovative work in software architecture, software engineering, and collaborative development environments. He has devoted his life's work to improving the art and the science of software development. Grady served as Chief Scientist of Rational Software Corporation since its founding in 1981 and through its acquisition by IBM in 2003. 

He now is part of the IBM Thomas J. Watson Research Center serving as Chief Scientist for Software Engineering, where he continues his work on the Handbook of Software Architecture. Grady has served as architect and architectural mentor for numerous complex software-intensive systems around the world in just about every domain imaginable.

 
Grady Booch : On Architecture : " Draw me a picture"

Text : http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=05672512


Great podcast :
http://www.computer.org/portal/web/computingnow/onarchitecture
Booch - On Architecture Podcasts

Aside from giving some guidance on what we're trying to do when we start drawing system architecures for discussion and posterity, this gives a summary of the values of architectural viewpoints.

He also presents a summary of the series so far.

Small Things

November 6, 2011 9:00 PM

Jim ("Cope") Coplien is an old C++ shark who now integrates the technological and human sides of the software business as an author, coach, trainer, and executive consultant. He is one of the founders of the software pattern discipline, and his organizational patterns work is one of the foundations of both Scrum and XP. He currently works for Gertrud & Cope, is based in Denmark, and is a partner in the Scrum Foundation. He has authored or co-authored many books, including the recently released Wiley title, Lean Architecture for Agile Software Development. When he grows up, he wants to be an anthropologist.

Uncle Bob honored me back in 2008 by asking me to pen the foreword to Clean Code
(Prentice-Hall, 2008). Though perhaps better known for writing about programming in-
the-large, I was being asked by Bob to reflect on the crucial issues of programming-
in-the-small. After all, the greatest mansion eventually reduces to its boards and
tiles, and the most ambitious creations in software are built brick upon procedural
brick. Small things matter.

In career, as in architecture and coding, there is a close tie between quality in
detail and quality of the whole. We can recall a host of cultural saws that
recognize and celebrate that relationship. He who is faithful in little is faithful
in much. A stitch in time saves nine. Mighty oaks from little acorns grow. An ounce
of prevention is worth a pound of cure. The architect Mies van der Rohe tells us
that God is in the details.

A paradox lurks here. A career is a grand notion that transcends decades and
thousands of individual acts. No one is under any illusion that we can define a
precise career destination and arrive there by taking exactly the right footsteps in
exactly the right order. Together, however, steps are guided by an underlying
compass needle, a broad goal.

Agile principles lie deeper still: the power of choice to change one’s compass
heading. We may do so to adapt to temporally short obstacles. More fundamentally, we
can choose to redefine the destination. To unthinkingly plod to a stubbornly fixed
destination can be a death-march. The mid-20th-century notion of “taking over
Daddy’s business” is one archetype of such paths. Agile careers recreate networks of
associations every day, because the world changes too much not to.

Pirsig, in Zen and the Art of Motorcycle Maintenance (William Morrow, 1974), offers
a metaphor linking the big picture with crucial details. “To strive only for some
future goal is shallow.  ... [I]t is on the sides of the mountain where things grow.
Yet, there are no sides without a top. The top defines the sides.”

If the path up the mountain twists and turns, and if we even switch to another
mountain now and then, what is the deep, underlying invariant? Pirsig suggests that
it might be caring. Caring plays out in the small things of life.  Any destination
is the accumulation of thousands of individual acts. So while the compass needle
points the way, our daily choices define the path. The destination can be foreseen,
but the path is defined only in retrospect.

You can make the grandest claims about being an engineer striving to make the world
a better place, but it is a hollow accomplishment if you climb on peoples’ backs to
get there. Accomplishment goes deeper than some goal: equally important to what you
do is who you are. As Pirsig reminds us:  the journey is on the sides of the
mountains.

Caring subsumes a host of ethical preconditions to any career. I opened my foreword
to Uncle Bob’s book with an anecdote about a Danish licorice box. Our Ga-Jol
licorice boxes all come with a witty saying printed on the inside of the lid. On the
morning of the day that I was to write the foreword I opened a box to the
admonition,  Ærlighed i små ting er ikke nogen lille ting. “Honesty in small things
is not a small thing.” Keep the big picture before you, but attend to excellence,
honesty, integrity, beauty, and joy in the small things of life. Big things will
follow.

[ Source :
http://www.computer.org/portal/web/buildyourcareer/Agile-Careers?utm_source=bronto&utm_medium=email&utm_term=Agile+Careers%3A+Small+Things&utm_content=colm.mulvey%40gmail.com&utm_campaign=CSMC-November+2011
]

Top Ten Idea Killers

Top Ten Idea Killers in Software Development
By Navneeth Mandavilli [@nmandavilli] -- October 3, 2011 12:48 PM

Software engineers start out as being curious, enthusiastic and gung-ho about getting things done. Somewhere along the way, they butt heads against a world that doesn't understand software development: systems that count engineers by numbers, productivity by lines of code and quality by process; a world where software development is a "risk-management" bureaucracy rather than a creative endeavor that can solve customer problems.

Unfortunately, many engineers consider this a wake-up call to shed their energy and adopt those bureaucratic ways, convinced that they have stepped into a new, adult world of "management". Some who manage to resist that misstep become disillusioned and don the garbs of martyrdom, ascribing every failure to something that management did or did not do.

If you are a software engineer, or an engineering manager, here's a list to help you identify if you still retain your software development genes or have morphed into someone that brings out a worn out list of cliches to robotically throw into every meeting, killing every idea and the morale behind it:

10. "This is good enough"
The fact is that nothing is ever good enough, least of all software. It may be good enough for today, or this release, but if your product has had the same problem for the last decade, some other company has already taken your customer away because of this feature. Fix it before you reach the point where you cannot.

9. "This is how it was always done"
This is an anachronism in any competitive, rapidly changing field, but particularly in software. Software companies are not like automobile companies that can set an assembly-line in place and forget about it for a hundred years. Oh, wait-a-minute! Even automobile companies can't do that anymore. Today's problems require a new set of solutions because we are dealing with machines; and machines, with people's expectations from them, change. And in an industry fantastically bound to Moore's Law, this is a terrific pace of change.

8. "There isn't enough time to do it right"
This is how you get into Technical Debt; some of it may be inevitable due to business pressures or working with a new piece of hardware or technology. As long as you repay this debt in the immediate future, this is part of the process; but if this is how you avoid making the right decision and the responsibility that goes with it, you are not being true to your engineering origins.

7. "This requires core architectural changes"
What doesn't? Ideally, a well-designed piece of software should be flexible and amenable to changes as the product develops. But as we've said, demands on software change rapidly and every piece of software written will need to be rewritten. This is the nature of the work, not an anomaly to be used as an excuse!

6. "Management has not prioritized it"
I always want to ask: what exactly hasn't management prioritized -- making a good product? writing error-free code? reducing bugs in the field? making the customer happy? Agreed that sometimes we inherit legacy code and there is juggling to be done be done between fixing what exists versus writing new code but this is a specious argument as we will see below. Suffice it to say that engineering needs to set and execute its own priorities, however small, every day, instead of waiting for some giant, magical mandate from above, because that's never going to happen.

5. "There is already a lot on our plate"
This is one of those nonsense tautologies that add nothing to the discussion. The focus is no longer the idea or how it should be executed but some longstanding grouse about 'having no resources' or some customer's bug list. Of course you have a lot on your plate! You are being paid to have that stuff on your plate -- start chowing down!

If an idea is worth executing, its adoption should not depend on whether you have a lot on your plate; if you fill your plate at the buffet with junk and decide you can't have a desired dish because your plate is full, you have done two things wrong: you chose the wrong things to begin with and then haven't done the simple math that you have to throw the junk off your plate to get what you want. You don't kill the idea, you clean your plate.

4. "Our software is very complex
we have to be careful about making changes": Check another nonsense tautology off the list. What enterprise software isn't complex? Are you saying you are usually not careful when writing code? You are a software engineer -- you are expected to deal with complexity and be careful about making changes -- that's a basic requirement. If this is a reason we as engineers cannot execute an idea, we need to go back to relearn the basics.

3. "No one is asking for it"
This reminds me of Henry Ford's wry comment "If I’d asked people what they wanted, they would have said a faster horse." Human beings are incredibly adaptable -- they will live with anything, including, as Ford observed, horse manure. If you give your customers a substandard product, they will live with it. But remember that humans are incredibly fickle, too; an idea you kill will only bloom in another company's garden. Being sloppy just because our software is "sticky" -- short for "the customer hates us but can't change because it's too much work" -- is setting the bar at a level that's not worthy of a true engineer.

2. "We have to have consensus"
This is at number two for a reason -- it's a seemingly innocuous statement with noble intent that is insidious and on closer inspection, meaningless in the software context. Consensus is given undue importance in everything from design meetings, SRS/SDS3 reviews, documentation, QA practices etc. Software development is an expertise-driven exercise. Someone has spent years studying, learning and working in a specific field, and to not defer to that person for the final decision is to waste all that expertise, not to mention deliver a bad product, demoralize the expert, adopt the safest and most timid way and most insidious of all, diffuse accountability.

A group decision is a way to duck responsibility for the outcome. "We all decided together" is a way of saying "No one is responsible". We have a presidential system instead of a parliamentary system for a reason: the congress advises the president but the president makes the decision.
Unless the decision is so obviously horrendous that 2/3rds of congress decides to override the decision, the president's decision stands. This is the only way the buck can stop at the president's desk.

And the #1 idea killer in software development is

1. "It can't be done":
There is nothing that cannot be done in software. Non-engineers kid around with "It's only software, right?" as a way to gently provoke engineers but it's true! It is indeed only software. Engineers should respond with specifics of what it takes to implement rather than say something cannot be done. A statement like "It will take 15 engineers, with individual licenses for software xyz, with 30 Model ABC machines, each with 2 TB of storage with at least 250GB in SSD storage and 5 QA personnel for a period of 1 year to deliver this software" instead of "it can't be done."

Everything can be done; let's get into that mindset first.

The rest will fall into place.

Wisdom of the Times

Wisdom of the Times

James "Cope" Coplien,   September 2011

One of my favorite books is "The Clock of the Long Now," edited by Stewart Brand. Brand will become a young man of 73 this 14 December. The book’s premise is that we who live now have a responsibility to the future. Ah, the past; the future. This is my third composition in a row that touches on the subject of time. My Season composition reflected on the fact that we can’t control our destiny in detail, but that, paradoxically, planning is important. The Routines reflection looked at the place of habit and cycle in life, and recalls Mary Poppendieck’s admonishment that we practice with deliberation. One theme common to these two perspectives is that we live in the now. But a good now is long, straddling past, present, and future.

While we are endowed at birth with various gifts, talents and abilities, most of our professional selves is nurture rather than nature. We are a product of our experiences: of the family that chose us to raise, of the schools we chose to attend, and of our chosen colleagues. Every now is worth treasuring as an opportunity to grow, improve, and to refine our influence. Planning helps us prepare for the opportunities that accelerate that growth. Ritual honors the human element and contextualizes our experiences to help us better integrate them into our whole selves. Improvement comes from time and attentiveness.

The most direct way to learn is first-hand experience from our work. Critical conversation with voices of experience can often be more efficient, optimizing our paths around needless blind alleys. King Solomon said, As iron sharpens iron, so one man sharpens another. Vicarious learning is often the best.

While we can reap benefit from any conversation, we should listen with particular care to the voices of those who have had time to collect and assimilate the world’s knowledge, and to demonstrate that they could act on it. It has been fashionable in engineering for some time now to put our faith in youth, but the most resilient ideas are woven from grey hairs. I think of Jeff Sutherland when he invented Scrum at age 52, building on previous careers in the military, medicine, and finance.

As I write this, I’m on my way to spend some days with a friend and mentor, Trygve Reenskaug, who invented MVC at age 47. We’ll be talking mainly about nerd stuff, though the discussion will build on our combined lifetime of experiences. But more than that, we’ll both draw on the many gifts of insight that accumulated in discussions with others over the years.

In planning your career, think about your stage in life and how it affects your contribution both to your firm and to society. Share your knowledge in open dialogue but be willing to be challenged either by broader, deeper and more general experience, or by a new perspective that causes you to realize that long-held beliefs might be arbitrary stereotypes or tribal beliefs. Find good mentors who have followed, or perhaps pioneered, the path before you. Just take the time to hear them out. Integrating their experience, though sometimes outdated, with your own life experiences increases the chances you’ll take the right paths.

If you feel you are smart now, but can see how wrong you were in the past, it’s worthwhile projecting yourself a decade or two into the future. You can often do this through the eyes of someone that age. Extend your now into the past through the eyes of senior people, and into the future through your dreams.

20 Management Observations

By Steve Tobak | June 13, 2011

Speaking of works in progress, here are 20 Powerful Management Truisms that have stood the test of time, up until now. Maybe “observations” is a better word since they come from my experience. Anyway, test them against your own experience and let us know what you think:

1. Strategy and execution complement each other; neither works without the other.
2. If you’re your own worst enemy, you’re sure to lose.
3. If you set out to build an empire, you’ll fail. All empires have humble beginnings. Just put one foot in front of the other, try not to stumble, and when you do, pick yourself up, dust yourself off, and try again.
4. If you’ve got loads of strengths, it’s okay to ignore your weaknesses. If you’ve got loads of weaknesses, you better work on them.
5. You don’t know squat. Once you think you’ve got things figured out, you’re in big trouble. Only fools have all the answers.
6. There are times to study and analyze and times to act decisively; the key is to know the difference.
7. A big ego is sufferable if the person delivers the goods.
8. Fear and desperation are powerful motivators, but they don’t always result in good or the right behavior.
9. One who actually gets things done is worth a dozen good-intentioned can-do attitudes.
10. Principles are a personal matter. Having them is good, pushing them on others, not so much.
11. Don’t take yourself too seriously or nobody else will either. Self-important people are just that - only important to themselves.
12. Leaders who make excuses and blame others don’t deserve their authority.
13. Coming in second is still losing. Still, learn from it.
14. What you think doesn’t matter half as much as what the other guy thinks. Better to listen than talk.
15. You get what you pay for. It’s true of goods, services, executives, employees, everything.
16. It doesn’t matter if you’re right or wrong, only if you win or lose.
17. If everyone’s out to get you, there’s probably a good reason for that. Look in the mirror.
18. Success depends on adapting quicker than your competitors do. It’s like the movie title The Quick and The Dead. Those really are the only two options anymore.
19. Play nice with the other children. It’s okay to spat as long as you apologize and make up. Playground rules work in organizations. Really.
20. Problems should be solved by those who discover them. An organization where nobody passes the buck is powerful.