Below you'll find a list of all posts that have been tagged as “software development”
I spent some time perusing the programming stacks at Seattle’s main library today, and skimmed through some texts on software architecture. Perhaps the most interesting was 97 Things Every Software Architect Should Know: Collective Wisdom from the Experts (ed. Richard Monson-Haefel). It’s a collection of various two-page thoughts from people who do software architecture from across the globe. Think Chicken …
A friend of mine encouraged me to tell this story which I watched unfold first hand while a software development manager for a mid-sized consulting firm. One of my best developers — a software architect, really — started laughing in the middle of the day. We all needed something to release the strain of our bi-weekly drop work, so all …
You can make money by taking advantage of people’s arrogance that the small stuff is idiot’s work. Sweating the details means raising the level of work up, not dumbing it down.
Software development groups almost always form a shadow hierarchy or pecking order of merit. Elliott Jaques’s theory of Requisite Organization explains why.
A new periodic feature. I wrote the following for another website. It describes the success that Glenn Mehltretter of PeopleFit has had in using Requiste Organization informed practices to create a better merger of two companies.
Some time ago, Gordon had an interesting comment about a couple of posts (see “Getting Work Done at the Right Level” and “Ready, Fire, Aim”: Intuition, Analysis and Tacit vs. Explicit Knowledge). I wanted to finally get around to addressing some of his points. I’m reading this just after reading your “Ready, Fire, Aim…” post, and just wondering “how do …
West reviews the philosophical underpinnings of the battle between structured programming and object-oriented programming. It’s an interesting read, as he goes back to the basic fight between the rationalist/formalist Enlightenment camp and their pesky detractors, variously called “hermeneutics”, “constructivist” or “interpretationalism”.
Raccoon describes the basics of learning curves — they go down and start at the top, so you actually want them to be as steep as possible to get back to parity and start process improvement. He points out that all people learn.
Jesse Poore, the University of Tennessee professor, is interviewed by ACM’s Ubiquity for his recent article in IEEE Computer, “A Tale of Three Disciplines… And a Revolution”. Poore talks about how if we made correct specifications, our software would work. While I agree that software should not fail as often as it does, I think that he misses the point …
They set out to understand why, if professional development is so important to their own careers and corporate performance, don’t more developers do it. They studied quite a few from several organizations and discovered, well, what I expected:
