September 12, 2016
I have been practicing software development for more than four decades now, and over that time, in addition to writing a lot of code, and being part of numerous projects in varying capacities, I’ve done a fair amount of reading on the topic. In fact, I have shelves full of books on the subject, starting with classics like The Mythical Man Month, proceeding through the CMM period and then on into the Lean/Agile years.
And, of course, the number of new words written on the topic increases daily.
How can a software developer keep up?
I’m a firm believer that new ideas are generated from time to time, and that it is worthwhile to read about software development as well as to do it; on the other hand, I’m now at the point of wondering whether it wouldn’t be possible to communicate the most important ideas about the field in a simpler, more concise, more easily accessible fashion.
And so I am setting off to test my hypothesis by trying to document the Big Ideas in Software Development in a concrete, manageable, sequential list.
Some of these ideas are specific to software development, but many have broader application; my primary intent is to include ideas that I’ve found most helpful over the years, and that I would want to recommend to others working in the field.
SoftDevBigIdeas.com describes Big Ideas, and not specific practices. Practices are important, but my experience has been that even the best practices can be misapplied and produce poor results if leaders and developers lack a solid understanding of these ideas, and so I’ve tried to focus on the ideas behind the practices.
Many of these ideas overlap and reinforce each other, but hopefully each adds something new and important to the collection as a whole.
I’ve included liberal citations from many of my favorite authors and works. In some cases I’ve incorporated these into my text and commented on them, but in others I’ve simply left them at the bottom of a relevant page for readers to enjoy, trusting that their pertinence to the ideas at hand will prove to be easily discernible. I’ve collected the sources of these citations into a generous bibliography that can be found in the Reference section.
I should warn readers up front that those who align themselves with a particular methodology or movement, such as Lean, Agile or Waterfall, may well be disappointed by some of what they find here. My own strong sense is that we’ve reached a point in the evolution of our thinking where these sorts of labels do more harm than good, and that it is time to rally around a set of shared ideas because they make sense, and because they have generally been found to work, without regard to what sort of branding they have been associated with in the past.
My intended audience for this work includes both those relatively new to the field of software development, as well as those who have been practicing this trade for many years. For the former, I hope it may provide a concise introduction to some of these ideas and, for the latter, I hope it may provide a useful reminder. In both cases, my intent is to offer a fairly complete, concise and balanced list of the ideas that bear careful consideration in any software development effort.
Software development is one of the riskiest human activities yet conceived: projects are often late or over budget, frequently canceled, and in many cases fail to find an appreciative audience even when they do reach a state of completion. Nothing I offer at SoftDevBigIdeas can guarantee the success of your next effort, but I do think that sincere and thoughtful consideration of the ideas presented there can increase your chances of success.
In any case, though, I’d be happy to hear your feedback on the site. Correspondence may be directed to email@example.com.
The new site is available now at SoftDevBigIdeas.com.
April 22, 2016
When companies attempt to implement lean principles, some of their biggest stumbling blocks seem to be the cultural elements. While some of the Toyota methods are very clear and specific, the cultural issues often seem more difficult to pin down. Many organizations seem to translate the most obvious elements into terms that they are comfortable with, but something often seems to get lost in the translation, and their lean implementations struggle because they have not really modified some of the basic ways in which they think about their work.
It occurred to me recently that the basic differences in lean culture might be represented in a very simple model. At first the simplicity of the model seemed to be too good to be true, but the more I thought about it, the more it seemed to help clearly explain some of the issues that typically cause the most confusion.
February 1, 2016
Many Agilistas view any discussion of architecture as the first step down a slippery slope that, once taken, will inevitably lead a project into the fiery pit of waterfall.
Let’s see if we can unpack this subject a bit, and possibly even reach agreement on a sensible way to do architecture on agile software development projects, especially large and complex ones.
December 5, 2015
In a corporate environment, the term “compliance” is often used to mean a number of different things.
The practice of following one or more sets of binding laws, regulations, policies and/or procedures.
An organization or function that is put in place to validate that compliance (in the sense above) is maintained.
The demonstration, or the ability to demonstrate upon demand, that compliance (in the first sense) is being maintained.
Compliance in the second and third senses above — what we might call the big “C” Compliance — often becomes most important in areas where failure to comply may produce long-term negative consequences, without any corresponding short-term issues or visibility. Information Security and Disaster Recovery Planning are good examples. Because there are no other quick feedback loops in cases like these, special oversight is often put in place to ensure that everyone is doing the right thing now to prevent or mitigate some possible catastrophe in the future.
In my experience, it’s important to keep in mind a number of key ideas in order to maximize the effectiveness of your compliance activities.
September 17, 2015
At the core of most of the important work done in this world you will find a small, multi-skilled team with effective leadership focused on delivering a product of value to a customer.
Note that teams such as these are found in contexts as different as Jazz bands, Rock groups, filmmaking, Agile Software Development and Lean Manufacturing, to name just a few obvious examples.
It’s now commonplace in business to take the work of teams for granted, but in my experience that passive acceptance doesn’t always translate into active support.
Let me break my opening assertion down, and explain the significance of each of its components.
July 29, 2015
The Apple Watch is much like the Velvet Underground: just as it was famously said by Brian Eno that not many people listened to the original VU albums, but all of them started their own bands, so it is true that “not many” people are buying the first generation of the Apple Watch, but all of them are writing their own reviews of it. And so here’s mine.
I’m a fairly tech-savvy guy who already has at least one of just about everything Apple makes. I’m six feel tall. I walk and run, but not competitively. I’ve worn a watch all my life.
I ordered the 42MM Steel Case with the Milanese Loop. Anything smaller would have looked silly on my big wrist. The steel case seemed much more like a real watch than the aluminum sport model. And I like the infinite adjustability of the Milanese loop, as opposed to some of the others. I also purchased a black Sport Band to use for running. And I also got a mophie watch dock to use for overnight charging.
July 26, 2015
There are a number of basic principles that those of us in the Information Technology field should have learned from the tremendous success of the Internet and the World Wide Web.
June 11, 2015
Many software development teams seem to treat “Agile” and “Project Planning” as if they were mutually exclusive concepts. The tendency, it seems, is to simply jump straight into Agile iterations — at best starting with an Iteration Zero — and then trust that things will sort themselves out strictly through a team-based Scrum-like approach.
In practice, though, teams seem to regularly run into trouble with this sort of naïve approach to starting up an Agile project — especially any sort of large, ambitious project operating within the context of a major enterprise.
Rather than proceeding blindly ahead with nothing more than faith in Agile iterations as a panacea, here are some of the planning considerations that I think projects should explicitly address at their outset, before their first sprint.
March 21, 2015
For those who have not yet heard of it, the Scaled Agile Framework, or SAFe® for short, is a “publicly available framework for applying lean/agile practices at Enterprise scale.”
I believe that the SAFe model offers a number of benefits to those who may be considering its use. Let me enumerate them.
December 14, 2014
I sometimes wonder if many of us in Information Technology are yet taking an informed perspective when contemplating investments in new software development efforts. Here are several things I think we should be keeping in mind.