Some long time ago I was working on a large software development project, and I wasn’t happy with either the quality or the velocity of our programming effort. So one night I sat down and tried to work out an activity diagram to show what our software development process needed to be, to improve both speed and quality. It turns out that a lot of this is just common sense, but for some reason or another team members would try to circumvent the process, which always led to more pain for everyone involved.
For the first time in many years I just came across Kent Beck’s Four Rules of Software Design:
- Passes the tests
- Reveals intention (should be easy to understand)
- No duplication (DRY)
- Fewest elements (remove anything that doesn’t serve the three previous rules)
There are wording variations on those rules, but I got those specific words from this Martin Fowler post. As he notes, “The rules are in priority order, so ‘passes the tests’ takes priority over ‘reveals intention.’”
For more information on Kent Beck’s Four Rules of Software Design, see that link, or this link to the original rules on c2.com.
When asked, “What is the value of learning lambda calculus,” Gary Bernhardt replied, “My favorite reason to learn a bit about the lambda calculus: it shows us 1) how simple computation is (at first it seems too simple to compute anything ‘real’); and 2) all of our programming complexity is invented by us (for reasons both good and bad).”
From a Ron Jeffries article, Dark Scrum: The case against the Sprint:
“Let’s consider the Scrum Sprint. What’s the strongest case we can make against it? We’ve already talked about the fact that Sprints are not necessary to teams who are working well: pulling one story, and swarming on it, then another and another, works better, my friends and I believe, than Sprints. (There are good reasons to continue a regular cadence of planning, and certainly of review and retrospection.) But that’s not much of a case. What else ya got?”
Steven Sinofsky has this series of 30+ tweets about Apple software quality.
I don’t know the original source of this image about “delegation” in computer programming (starring Inigo Montoya of The Princess Bride), but I like it.
Summary: I use Function Point Analysis (FPA) and Yesterday’s Weather to make “back of the envelope” software cost estimates when discussing potential new software projects with decision makers.
Many times when a software project is in its earlier stages (the conceptualization phase), the people that control the money at an organization (the CEO, CFO, CIO, etc.) want the best estimate they can get regarding the time and cost of a software development project. This is often very early in the project lifecycle, typically shortly after someone said, “Hmm, that sounds like a very interesting idea” and well before the first check is cut. In short, they want the best back of the envelope, ballpark cost estimate you can give them.
I used to dread these discussions, because I hated estimating the time and cost of software projects. I wasn’t any good at it, and the developers I worked with weren’t any good at it either. But once I learned two things:
I was going to write a little application to let me annotate my MacOS screen during presentations, but the Ink2Go product looks like it does exactly what I was thinking. As I’m creating a video presentation, such as when showing how to write some Scala or Android code, I want to be able to draw on the screen, such as writing text, arrows, circles, and boxes to highlight parts of the screen. Ink2Go looks like what I want.
Tried to use someone’s software library.
Documentation was bad, couldn’t get it to work.
Used someone else’s.
I just learned that MacOS has a softwareupdate command, and further learned that it has a --ignore option, which may or may not let you ignore useless updates. For example, my Mac prompts me daily to update Keynote, Numbers, and Pages, which I rarely (rarely!) use, so I don’t want to bother updating them. I’m hoping the a
softwareupdate command will help me with this.