Way back in the late 1970s and early 1980s the U.S. economy wasn’t doing very well, and Dr. W. Edwards Deming wrote about his 14 Points for Management as a way to improve the economy. (The image shown comes from that link at deming.org.)
Posts in the “best-practices” category
Over the last 18 months I've been working with a 24x7 manufacturing group, and no matter what I say, they always have the same two requests/demands:
- The software system must not fail, and
- If it does fail for some reason, it needs to be able to recover properly from the failure.
Simply put, (a) the machines must keep moving, and (b) nobody wants the phone call in the middle of the night when the machines stop moving.
Software healing component #3: The self healing program
In the first two parts of this tutorial I wrote about a worker program, and the functionality it needs to provide to support a self-healing architecture. In the second part I wrote about an open source program named Nagios, which can be used to monitor your worker programs. In this third part of the self-healing recipe, I will now write about what is necessary for the "healing" component.
Component #2: The software monitoring program
The second piece of the self-healing architecture is to have a program that monitors your worker programs. You can write your own software monitoring program, as I did many years ago, but that's pretty old-school, and frankly, not a good idea any more.
If you’ve never read the book Use Case Driven Object Modeling with UML by Doug Rosenberg and Kendall Scott, you’re missing one of the most simple and important Model-View-Controller (MVC) diagrams in the software business.
In their discussion of Robustness Diagrams they introduce a figure called “Robustness Diagram Rules” that succintly tells you how to implement an MVC design in your code. In one figure they tell you:
There is a disease I see so often in the software development industry that I've decided to give it a name. I call it "Kirk/Scotty Syndrome". This disease is related to the concept of "software rot" and "spaghetti code" inflicted by the management team. You'll know this disease when you hear it, because it will sound a lot like the following conversation, taken from most Star Trek episodes:
In the software development industry, the physical distance between developers and users is an important, often-overlooked variable to the success of a project. I'm currently working on a project where my development team is several hundred yards away from our users, and we're also in another building. Because developers don't seem to like telephones, or perhaps don't like talking to other people that aren't developers, I contend that this 300 yards could easily be 30 miles.
I was recently reminded of the danger of leaving less-experienced software developers alone to create new functionality in a technical area where they have no prior experience. For instance, suppose you have one or more good but less-experienced developers, and you ask them to work in a technical where they have no prior experience. These aren't totally inexperienced developers; they may each have at least five years experience. Given that their are other people on the team with experience in this area, how do you think this should be handled? Choices include:
Note: This is a post from 2007 that I just updated a little bit because I think there’s still some value in it.
A lot of people have written to say that it’s unfair that I think developers should never say “I’m 75% done,” or “I’m 90% done.”
So, to explain myself, here’s why I think you should never use a phrase like that:
Here's a brief list of some of the most obvious, and important, team-level best practices I know for software development:
Anti-practice: The karma of bad estimates and not communicating in the process of software development
A quick lesson on the karma of getting and accepting bad estimates from developers, and not communicating:
A lot of times I'm asked about software best practices, but sometimes it's easier to show a best practice by showing its opposite -- a "worst practice". With that, today I introduce you to a worst practice I call "The Pigpen Developer".
Just cleaning up around here lately, it looks like I never really linked up to some of the cost estimating and Function Point Analysis (FPA) tutorials and slide shows I've created. So without any fruther ado, here are some links to my free FPA tutorials and presentations:
Following a speech two days ago, I'm struck by how very little we use the Unified Modeling Language (UML) on our software projects. Occasionally I'll create some activity diagrams to model how users get their tasks done, but that's about it. Typically when we create a software requirements specification this is what we deliver:
The last few weeks I've been looking at ways of estimating software development projects using "Use Cases". I'm all over Use Cases -- I think they represent a good way to document the flow of an app, but a significant problem with them is that your use case is not the same as my use case, even for the same subset of an application. This leads into many problems estimating how much it's going to cost to develop a software app.
“When someone learns to drive a race car, one of the first lessons taught is that when you are going around a curve at 200 mph, do not focus on the wall; focus on the road. If you focus on the wall, you will drive right into it. If you focus on the road, you follow the road. Running a company is like that.”
~ Ben Horowitz, The Hard Thing About Hard Things
It's so rare that a CEO talks in detail about how their company generates revenue that I want to take a moment and share this TechCrunch link, which covers Evernote CEO Phil Libin's presentation at a meeting named Founder Showcase. Mr. Libin discussed some of the elements of making the "freemium" business model work.
One philosophy I have about writing technical material is that I want to condense the material as much as possible, to the point where I want people who use yellow highlighters to mark most of what I write. I am one of those people who use yellow highlighters, and I look for that property in books that I read.
This isn’t necessarily true for blog posts that I write, because for these I usually write them pretty fast. But for books, I take the time to review them and look for this quality. This follows the design mantra, “reduce, reduce, reduce.”
In his book, The Universal Tone: Bringing My Story to Light, Carlos Santana writes about hearing other guitar players, and wondering with an intense curiosity how those other people got their guitars to make the sounds they made. As I thought about this I thought it was a good attitude to have in programming. For instance, if I look at an application where someone has done something really cool I try to understand, “How did they do that?”
One Java programming "best practice" that has been strongly reinforced for me during the last several weeks is making sure you have a declared interface that defines the behavior (signature) of your Dao (data access objects) classes.