I took a brief break from writing about software to write about cardboard creations (there will be more), but now I’ll come back to writing about software. Specifically, I want to talk about the small team and how to actually get things done. Continue reading “Getting Things Done With A Small Team”
Tag: SDLC
Lean and the Team
In my last post, I talked about comparative advantage and how it can aid you in developing your team and your members’ skills. Now, I’ll talk about another aspect that you need to consider in a lesson from Lean.
I have never described myself as a person who espouses any one single methodology for solving problems, so you won’t ever see me write about the one right way of doing things. Many processes and frameworks were originally designed for one thing, and I have had uneven results applying them to software development. One thing that I have found to be very helpful in developing a team is a specific subset of the Lean concept of muda, which I came to understand when reading the book The Goal.
If you haven’t read this book, it’s highly regarded and a bestseller for making certain business concepts very accessible to the reader. I highly recommend it.
The book has two great takeaways – first is the answer to the question: What is the goal of a company? The answer: To Make Money. It’s a very handy thing to keep in mind.
The second takeaway is the Theory of Constraints. This is the idea that production bottlenecks can take an assembly line and slow it to the speed of its slowest machine. Continue reading “Lean and the Team”
Books about Software Development: Life the Universe and Everything
Most readers will be intimately familiar with Douglas Adams’ work. If you’re not, it’s definitely worth a read. One item that relates to engineering and project planning that always springs to mind too late in a project was a concept he included in Life, The Universe and Everything: The ‘SEP’ – ‘Somebody Else’s Problem’.
This concept is basically a sort of cloaking field where people ignore something by assuming it’s somebody else’s problem.
“An S.E.P., […] is something that we can’t see, or don’t see, or our brain doesn’t let us see, because we think that it’s somebody else’s problem. […] The brain just edits it out; it’s like a blind spot.”
—Douglas Adams. Life, The Universe and Everything, Chapter 3 Continue reading “Books about Software Development: Life the Universe and Everything”
Four Quadrants
A while ago I was in my car, listening to the radio, and the Beatles came on. I’ve never really been into them, but I have respect for them and their influence on music. I started to think about my likes and dislikes in four quadrants as sort of a silly thought experiment:
On the Y axis is my level of respect for something, and on the X is how much I like something. Continue reading “Four Quadrants”
Fear and Software
Several years ago, as a consultant, I had the opportunity to work with a client on modernizing their Quality Assurance processes. At the time, I was at the phase of my career where I viewed QA as just ‘testers’. They were sort of secondary characters in a play that starred programmers. Like the ponies in the Lord of the Rings. Important, sure, but they didn’t get their own swords or anything.
So I took a deep dive in to Quality and started at (close to) the beginning, with W.E. Demming. He was one of the first Quality gurus, and became known for his work in Japan following WWII (he has a wikipedia page). The one thing that really resonated with me from researching him was his idea that you had to drive out fear from engineering. At the time, I was still in the ‘bugs are bad’ phase, and because of that, made all the classic mistakes in programming. I wasn’t good at testing my own work, and wasn’t particularly good at telling our testers where to look for bugs. I also viewed testers more as impediments to my amazing software being released than as allies. Continue reading “Fear and Software”
You Should be Good at One Non-Engineering Discipline
I have a theory that the best software developers are also really good at some discipline that involves putting things together that is tangible. By ‘tangible’, I mean that software engineering generally involves resources that you can’t actually hold, like time or code or computation. It’s much harder to understand consequences when all your problems are abstract.
So take, for example, cooking. If you wanted to prepare the following meal for your family:
- Pasta with home-made tomato sauce
- Chicken, marinated for over 30 minutes
- A simple salad
and the goal was to have dinner ready at 7, with each of the 3 parts done at the same time, so that the hot dishes were hot and the kids got to bed on time, you need a pretty complex project plan. It doesn’t have a lot of elements, but it does have a lot of parallelism and mode switches, plus some dependencies. Continue reading “You Should be Good at One Non-Engineering Discipline”
Possible But Not Practical
I recently was working on a project and got in one of those discussions where I was not communicating at all. I was trying simultaneously arguing that the software was something I could build, but one that would not work. I felt pretty confident in my abilities to build and deliver it, and, in fact, that it would be pretty cool once built.
However, I was also trying to indicate that because of its complexity, it would have the characteristics of an unstable nuclear isotope – it would not last long. The system in question wold require so much more human intervention to keep it correct than was available within the organization that every month of operation would put it further and further out of true. It was ‘Possible, but not Practical’. Continue reading “Possible But Not Practical”
The Incident Pit
I’ve been reading Alastair Reynolds‘ work since I stumbled upon his short story ‘Galactic North’ in an anthology in 2000. His work is awesome and interesting, and one thing that has stuck with me as an engineer is the idea of an ‘Incident Pit’ from Pushing Ice.
When I went back and googled it, it turns out that this concept has a whole wikipedia page about it (albeit a short one). It’s worth checking out. TL;DR: it’s when a project or scenario’s incidence of errors begins to rise faster than they can be handled. It’s based in diving, where there are constant errors, and if an inflection point occurs, and error rates grow too fast, fatal mistakes can happen. Continue reading “The Incident Pit”
Vertical Integration
One of the coolest things about Tesla’s business, apart from its success and all that, is the use of vertical integration. Elon Musk does this as well with SpaceX. I think software engineers have a lot to learn from this. We have a tendency to specialize, and it leads to inefficiencies in what we do.
One area of interest here is Development Operations. A common case with DevOps is that the DevOps technicians are shared resources, and developers sort of shrug and assume someone else will set up the Web server, security, load balancers, etc., and DevOps in turn assumes that the developer has taken these same things into account as they wrote their software.
Increasingly granular models of SDLC, which have moved to digestible ‘stories’, have further moved the developer away from the infrastructure and servers. Continue reading “Vertical Integration”
A Quantum of Programming
As I’ve worked through almost two decades as a software developer, I’ve often wondered about the relationship between time and features. Basically, should the ‘explainability’ of a feature be proportional to its time to develop. I think it should. This can be generalized as: A small feature should take a small time to develop.
In physics, a quantum is the smallest divisible amount of energy that a thing can have. In software, I think that a ‘Quantum of Programming’ is the smallest unit of work that is actually a piece of usable software. Continue reading “A Quantum of Programming”