Tag Archives: systems

Post navigation

When you’re building software, it is probably best to look at things half-Buddhist. Kent Beck writes about building software that won’t be around longer than him in a recent Facebook note:

…nothing I am doing now with software will remain in a hundred years. Indeed, there was a time not long ago when the only software I had ever written that was still running was JUnit. Thousands of programs started, and my work was in danger of becoming extinct.

I could try to achieve timelessness in my designs and encourage others to do the same, but in the end nothing I program will outlive me. It would be easy to despair over this, to go into my shell and settle for “good enough”. To do so would be to ignore both the immediate impact of my work, used by hundreds of millions of people today (one of the great things about working at Facebook), and the second order effects of my work on the lives and attitudes of others. No, my programs won’t be here in a century, but my work still matters.

Related:

Michael Mehaffy and Nikos Salingaros: “The Pattern Technology of Christopher Alexander”: “We have to remember that software engineers, by nature of their work, have a big problem. Their job is not to solve problems for computers, but for human beings; the computers are only tools in that process.”

My boss back at Bell Atlantic, who became my friend and mentor, Pat Trongo, had the following quote from Peter Senge’s “The Fifth Discipline” on his cube wall in big bold letters.

I found it inspirational back then. But now I am blessed to see evidence of this pattern in life daily – Great teams committed to a purpose accomplish great things.

The committed person brings an energy, passion,
and excitement that cannot be generated if you
are only compliant, even genuinely compliant.

The committed person doesn’t play by the rules
of the game. He is responsible for the game.

If the rules of the game stand in the way of
achieving the vision, he will find ways to change
the rules.

A group of people truly committed to a common
vision is an awesome force.

They can accomplish the seemingly impossible.

I am as blown away by this as I am with the OccupyPhilly protest teamwork I saw today, as I am with my co-workers who are one of the greatest teams I’ve seen in my career.

Great teams are everything. They don’t just ‘happen’ and require investments in trust, empathy, accountability, honesty, and crazy foolishness to grow. And when you see them you can’t help but be in awe.

Edsger W. Dijkstra gave a lecture, in 1972, that has since been come to be called “The Humble Programmer”. It’s a short piece that explains why software development, why programming, was growing more, not less complex over time, and some inspiration to be found in the dealing with it. There’s some choice quotes in here that I’m going to include, but read the whole thing.

On LISP:

With a few very basic principles at its foundation, it has shown a remarkable stability. Besides that, LISP has been the carrier for a considerable number of in a sense our most sophisticated computer applications. LISP has jokingly been described as “the most intelligent way to misuse a computer”. I think that description a great compliment because it transmits the full flavour of liberation: it has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts.

Lets call it TDD before TDD was coined:

Today a usual technique is to make a program and then to test it. But: program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence. The only effective way to raise the confidence level of a program significantly is to give a convincing proof of its correctness. But one should not first make the program and then prove its correctness, because then the requirement of providing the proof would only increase the poor programmer’s burden. On the contrary: the programmer should let correctness proof and program grow hand in hand.

On decomposing systems:

It has been suggested that there is some kind of law of nature telling us that the amount of intellectual effort needed grows with the square of program length. But, thank goodness, no one has been able to prove this law. And this is because it need not be true. We all know that the only mental tool by means of which a very finite piece of reasoning can cover a myriad cases is called “abstraction”; as a result the effective exploitation of his powers of abstraction must be regarded as one of the most vital activities of a competent programmer. In this connection it might be worth-while to point out that the purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise. Of course I have tried to find a fundamental cause that would prevent our abstraction mechanisms from being sufficiently effective. But no matter how hard I tried, I did not find such a cause. As a result I tend to the assumption —up till now not disproved by experience— that by suitable application of our powers of abstraction, the intellectual effort needed to conceive or to understand a program need not grow more than proportional to program length. But a by-product of these investigations may be of much greater practical significance, and is, in fact, the basis of my fourth argument. The by-product was the identification of a number of patterns of abstraction that play a vital role in the whole process of composing programs. Enough is now known about these patterns of abstraction that you could devote a lecture to about each of them.

On education:

As each serious revolution, it will provoke violent opposition and one can ask oneself where to expect the conservative forces trying to counteract such a development. I don’t expect them primarily in big business, not even in the computer business; I expect them rather in the educational institutions that provide today’s training and in those conservative groups of computer users that think their old programs so important that they don’t think it worth-while to rewrite and improve them. In this connection it is sad to observe that on many a university campus the choice of the central computing facility has too often been determined by the demands of a few established but expensive applications with a disregard of the question how many thousands of “small users” that are willing to write their own programs were going to suffer from this choice. Too often, for instance, high-energy physics seems to have blackmailed the scientific community with the price of its remaining experimental equipment. The easiest answer, of course, is a flat denial of the technical feasibility, but I am afraid that you need pretty strong arguments for that. No reassurance, alas, can be obtained from the remark that the intellectual ceiling of today’s average programmer will prevent the revolution from taking place: with others programming so much more effectively, he is liable to be edged out of the picture anyway.

There may also be political impediments. Even if we know how to educate tomorrow’s professional programmer, it is not certain that the society we are living in will allow us to do so. The first effect of teaching a methodology —rather than disseminating knowledge— is that of enhancing the capacities of the already capable, thus magnifying the difference in intelligence. In a society in which the educational system is used as an instrument for the establishment of a homogenized culture, in which the cream is prevented from rising to the top, the education of competent programmers could be politically impalatable.

On recognizing the difficulty, challenge, and opportunity:

Automatic computers have now been with us for a quarter of a century. They have had a great impact on our society in their capacity of tools, but in that capacity their influence will be but a ripple on the surface of our culture, compared with the much more profound influence they will have in their capacity of intellectual challenge without precedent in the cultural history of mankind. Hierarchical systems seem to have the property that something considered as an undivided entity on one level, is considered as a composite object on the next lower level of greater detail; as a result the natural grain of space or time that is applicable at each level decreases by an order of magnitude when we shift our attention from one level to the next lower one. We understand walls in terms of bricks, bricks in terms of crystals, crystals in terms of molecules etc. As a result the number of levels that can be distinguished meaningfully in a hierarchical system is kind of proportional to the logarithm of the ratio between the largest and the smallest grain, and therefore, unless this ratio is very large, we cannot expect many levels. In computer programming our basic building block has an associated time grain of less than a microsecond, but our program may take hours of computation time. I do not know of any other technology covering a ratio of 10/10 or more: the computer, by virtue of its fantastic speed, seems to be the first to provide us with an environment where highly hierarchical artefacts are both possible and necessary. This challenge, viz. the confrontation with the programming task, is so unique that this novel experience can teach us a lot about ourselves. It should deepen our understanding of the processes of design and creation, it should give us better control over the task of organizing our thoughts. If it did not do so, to my taste we should not deserve the computer at all!

It has already taught us a few lessons, and the one I have chosen to stress in this talk is the following. We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers.

Wondering why we’re living in an age of ever increasing decreased expectations? You are not alone. Author Neal Stephenson wrote a thought provoking must read for World Policy Institute titled, “Innovation Starvation”:

The imperative to develop new technologies and implement them on a heroic scale no longer seems like the childish preoccupation of a few nerds with slide rules. It’s the only way for the human race to escape from its current predicaments. Too bad we’ve forgotten how to do it.

In “Screaming Architecture” Uncle Bob lays out one of the biggest wins by designing to the problem domain, instead of your weapon (ahem.. framework) of choice:

“If you system architecture is all about the use cases, and if you have kept your frameworks at arms-length. Then you should be able to unit-test all those use cases without any of the frameworks in place. You shouldn’t need the web server running in order to run your tests. You shouldn’t need the database connected in order to run your tests. Your business objects should be plain old objects that have no dependencies on frameworks or databases or other complications. Your use case objects should coordinate your business objects. And all of them together should be testable in-situ, without any of the complications of frameworks.

Martin Fowler wrote a piece in 2003 that addresses a subtle anti-pattern – developing your domain model code devoid of behavior. It’s a short, interesting read, that is related to the development of fat controllers in MVCish applications: “AnemicDomainModel”:

“In general, the more behavior you find in the services, the more likely you are to be robbing yourself of the benefits of a domain model. If all your logic is in services, you’ve robbed yourself blind.”

…As the fast in fast fashion implies, the companies’ comparative advantage lies in speed, not brand recognition, garment durability, or reputable design. They have changed fashion from a garment making to an information business, optimizing their supply chains to implement design tweaks on the fly. Zara “can design, produce, and deliver a new garment and put it on display in its stores worldwide in a mere 15 days,”2 and this flow of information is by far the most significant thing the company produces, far more important than any piped pinafore, velveteen blazer or any of its other 40,000 yearly items. The company’s system of constant information monitoring allows it to quickly spot and sate trends and at the same time largely avoid overproduction boondoggles and the need for heavy discounting.

Unlike earlier generations of mass-market retailers, like the Gap’s family of brands (which includes, in ascending order of class cachet, Old Navy, Gap, and Banana Republic), companies like Zara and Forever 21 make no effort to stratify their offerings into class-signifying labels. They also don’t adopt branding strategies to affiliate with particular luxe or ironic lifestyles, à la Urban Outfitters or Abercrombie & Fitch. Instead they flatter consumers in a different way, immersing them in potential trends on a near weekly basis and trusting them to assemble styles in their own images. Clothes reach stores with practically unspoiled semiotic potential, and consumers are invited to be expressive rather than imitative with the goods, to participate more directly in fashion. We become the meaning makers, enchanting ordinary cardigans and anoraks with a symbolic significance that has only a tenuous relationship to the material item. We work in lieu of advertisers to reconfigure trends and remix signifiers, generating new and valuable meanings for goods. The more new clothes come in, the more creative we can be.

Fast-fashion retailers reap the fruits of that creativity by capturing our preferences in successive generations of products and nearly synchronizing to our whims. Thanks to the rich data we generate as we select, reject, and recombine the items fast fashion offers, the companies need not develop their own brands so much as seize upon customers’ ingenuity, distilling their choices into easily replicable trends and rushing the resulting products to market. If fashion functions like a language, then the fast-fashion firms are mainly interested controlling the underlying system and leave the meaning of the “words” to interchangeable designers and individual consumers. As long as customers are willing to speak fast fashion’s language, the companies aren’t particular about the specifics of the vocabulary. They are concerned only with the rate and volume of change.

…Like fast fashion, social media have brought with them a profusion of means and ways to reshape and display our identity. Constantly given new tools to share with, always prompted to say something new about ourselves (“What’s on your mind?” Facebook asks thoughtfully), we are pressured to continually devise ingenious solutions to our identity, which suddenly appears to be a particular kind of recurring problem: one that can be solved by replenishing social media’s various channels with fresh content. Just as fast fashion seeks to pressure shoppers with the urgency of now or never, social media hope to convince us that we always have something new and important to say—as long as we say it right away. And they are designed to make us feel anxious and left out if we don’t say it, as their interfaces favor the users who update frequently and tend to make less engaged users disappear. One can easily fall out of fashion with the algorithms Facebook uses to select which content users see out of the plethora of material friends in their network contribute.

…In social media, where everyone can employ design ideology, the persistent messages of advertising—that magical self-transformation through purchases is possible, that one’s inner truth can be expressed through the manipulation of well-worked surfaces—become practical rather than insulting. Not only do the methods and associative logic of advertising become more concretely useful, but its governing ideology no longer seems conformist but radically individualistic. Social media encourage us to appropriate whatever we want and claim it as our own without feeling derivative or slavishly imitative. On Facebook, if I link to, say, a YouTube video of Bob Dylan singing “I Threw It All Away” on the Johnny Cash Show in 1969, I am saying something particular about myself, not merely consuming the performance. I am declaring that video clip to be essentially equivalent to an update I may have written about a trip to Philadelphia or to pictures of me at a party that someone might have tagged. It is all bricolage for personal identity building.

As a community of developers and technologists, we have to build powerful, indispensable apps and services on top of this data. Killer apps that save lives. If we can make ourselves invaluable, they won’t have the chance to try to cut off our oxygen.

Read Umair Haque’s Builders’ Manifesto and get inspired. Screw that actually. Put it into action. Be it. Because the organizations we are part of need it to navigate the fast pace of change. Because our communities need us to act and make a difference. Because the world needs more than words to move the needle in a positive way. For more thoughts on this piece, Joe Campbell. Now for some quotes, including how you can be a builder:

I’ve been thinking a lot about leadership lately. Specifically: why, today, when a wave of crises is sweeping the globe, does leadership seem to be almost totally absent?

The answer I’ve come to is, ironically enough, leadership itself.

…Here’s the problem in a nutshell. What leaders “lead” are yesterday’s organizations. But yesterday’s organizations — from carmakers, to investment banks, to the healthcare system, to the energy industry, to the Senate itself — are broken. Today’s biggest human challenge isn’t leading broken organizations slightly better. It’s building better organizations in the first place. It isn’t about leadership: it’s about “buildership”, or what I often refer to as Constructivism.

Leadership is the art of becoming, well, a leader. Constructivism, in contrast, is the art of becoming a builder — of new institutions. Like artistic Constructivism rejected “art for art’s sake,” so economic Constructivism rejects leadership for the organization’s sake — instead of for society’s.

Builders forge better building blocks to construct economies, polities, and societies. They’re the true prime movers, the fundamental causes of prosperity. They build the institutions that create new kinds of leaders — as well as managers, workers, and customers.

…How can you become one? Here are the ten principles of Constructivism (contrasted with these principles of leadership).

The boss drives group members; the leader coaches them. The Builder learns from them.

The boss depends upon authority; the leader on good will. The Builder depends on good.

The boss inspires fear; the leader inspires enthusiasm. The Builder is inspired — by changing the world.