As a business analyst — or any person interested in writing software requirements and quality — there is one thing you should always ask yourself whenever you write a business requirement:
Is this software requirement testable?
I’ve seen some business analysts write some crazy things and call them requirements, but IMHO, if you can’t test it, it’s not a requirement.
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".
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:
I was reading Dr. Dobbs last night, and they referenced this story about how quantity ends up producing quality, at least when it comes to humans creating things.
The lesson goes like this: A ceramics teacher divides a class into two teams, then tells one team they'll be graded by sheer quantity, while the other side has to produce one great pot. In the end the Quantity Team delivers all the best quality pots.
I've found this to be true with new programmers. All newbies want to learn about things like design patterns, but what they really need to do is just sit down and write a lot of code.
This reminds me of the quote, "One learns by doing the thing." I don't know for sure who said that — possibly Sophocles — but I remember reading it in a Thermodynamics book in college, and I've never forgotten it.
(Note: I originally wrote this article in 2010 or 2011, but I tend to like articles that I wrote while in the midst of a ton of design, programming, and testing work, and this is one of them.)
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:
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.
As I was just cleaning up around the website lately, it looks like I never linked up to some of the software 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:
For more information on Function Point Analysis, I recommend looking at the International Function Point User's Group (IFPUG) web site. IFPUG is the non-profit organizational body for the FPA industry, and provide certifications, such as my former Certified Function Point Specialist (CFPS) certification. (I let that expire, as I don't have an interest in counting function points in general, just for applications that I'm involved in developing.)
“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
While driving through the mountains in Alaska and Canada in the winter, you learn a similar lesson: Focus on the road, not falling off the cliff. :)
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?”
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.)
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.
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.
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:
A quick lesson on the karma of getting and accepting bad estimates from developers, and not communicating:
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.
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.
