Nope, I’m not talking about extravagant costumes, black and white face paint, and fire breathing.
I’m here to discuss the old adage “Keep it simple, stupid” and how it applies to software development.
As a Project Manager, I spend a lot of time meeting with clients to review requirements for their software and work with them to turn those requirements into a full system. As I work with my clients to navigate the treacherous waters of system design, we inevitably end up with a “feature” that we all agree is on the borderline of “Necessary” and “Nice to have.” This is especially hard to determine in a business system that users will be working with every day.
This is when things get interesting! Let’s take a look at what questions to ask yourself:
Why do you want this feature?
You can tell a lot about how important this feature really is by the initial reaction of a client when you ask this question. If it takes a few minutes of fumbling to eek out a satisfactory answer, you can most likely scrap the feature.
Is it worth it?
To answer this one, we’ll ask a few follow up questions, too:
- How often will this feature be used?
- Is there a manual workaround that can be used instead of this feature?
- Who will use this feature (and how many of these users are there)?
- How much work will be created for a user is this feature is left off?
Now do a little quick math and, magically, we can determine if it’s financially worth adding this feature. Here is an example:Add this monthly report that aggregates data for X, Y and Z.
- Feature will be used monthly
- User can perform this process manually
- 1 administrative user will use the report
- If this feature isn’t implemented, the administrative user will need to run 3 reports and aggregate the data themselves. This process will take approx. 20 minutes.
Answer: If building the report adds 8 hours to the system build, it will pay for itself in 2 years.
Does this feature add complexity to other areas of the system?
I’ll let you in on a little secret, the answer to this question is always YES.
No mater how much you want this fancy new feature, it will make your system more complex. We often try to convince ourselves that a feature is so simple that it won’t add complexity, but there are a couple of points that always hold true:
- This feature will need to be tested after every update.
- The users of this feature will need training.
- This feature will need to be documented in the help system (and maintained).
- This feature will need to be discussed when future changes to the system are designed/implemented.
So, let’s return to our seemingly simple example report and apply these issues to the “complexity” question:
- Will this report need to be tested? Yes
- Will the users need training? Yes
- Will we need to add help documentation? Yes
- Will this report need to be updated if we make changes to report X, Y or Z? Yes
There’s no doubt about it–every time you want to add a feature, you’re choosing to make the system more complex.
Before you commit to a feature, ask yourself if it’s a system requirement and make sure you really understand, and accept, the increase in time, complexity, and cost that including the feature will entail. If the answer is “yes,” then let’s build it. But if there’s any doubt, remember, it’s never a bad idea to K.I.S.S.