One of real challenges with custom software is maintenance after the fact. There are always trade offs being made for cost over flexibility. An example that has been a thorn in my side for quite sometime now are business processes developed with no way to plan exceptional cases by a business user. I think the mistake here is idenification of what type of process you are working on. Software developers look at processes and are inclined to think “technology process” not “business process”. With a “tech process” such as rolling logs or backing up files a developer would be right to have assume no exceptional cases are necessary to be administered by a business user. But a nightly business critical process such as moving approved changes or clearing processing queues needs to able to be administered by business users otherwise there will be duplicated efforts, both a business user and a engineer will need to assist. Identifying proper administration over processes will reduce support cost and produce a system which has the necessary flexibility to support the business process.
Posts Tagged ‘process’
One principle in software engineering is “Don’t Repeat Yourself”. It has been around for as long as I can remember and is the hallmark in many cases of good code. Many times I think developers fundamentally get stuck in this “don’t repeat yourself” mode outside of the code because we train ourselves so much to be constantly thinking about efficiency. Because of this, it creeps into places where it shouldn’t be. And gives developers like myself an excuse to say “we don’t need that document because the information will be in another document” or “just look at the code if you need to know something”. Both are certainly good justifications in some situations, however they don’t always hold up. I want to throw out some ideas for when its OK to repeat yourself to counter balance the efficiency junkies in all of us.
Where is “Don’t Repeat Yourself” abused?
In code its rare where “Don’t repeat yourself” fails because if it didn’t work then the compiler or testers would tell you. That’s the simplicity of code but the places that I see “don’t repeat yourself” being used as an excuse to avoid additional work…
- Developer to Developer Communication – I’ll single out us developers here but its not necessarily a unique problem. A developer likes to communicate in the most efficient way for himself. One of the main ways we do that is by trying to not have to repeat ourselves when we communicate things. For instance we’ll send out a group wide email or we’ll schedule a meeting to train everyone at once and assume everyone got the message. The problem is you need to repeat communication in many cases because people simply don’t understand (or listen) the first time.
- Documentation – In some cases the misuse here is trying to combine documents which have similar content but need different levels of detail to cater the correct audiences. The main offense I’m thinking of though is not repeating yourself in documentation because someone can just look at the code. This applies to documentation meant for other developers mainly, especially when someone put work into in-code documentation. The issue isn’t that the source code can’t explain exactly what is happening, it’s that if you plan on having additional people work on the project it increases ramp up time eliminating any time saved previously.
Repeating Yourself = OK
There are a couple of situations which repeating yourself is probably not a bad idea…
- Different audiences – Anytime you are preparing something for two different sets of people with different perspectives on an application/system, it’s probably a good guess that you’ll need to repeat yourself in either a different format or different level of detail.
- Buried Information – Many times you’ll have information which is important but gets lost in a larger document or system. When this happens consider repeating it again in a place which is appropriate for the level of importance.
- Inability to Properly Cross Reference – When you create anything which is dependent upon another piece of information and your not able to actively reference that piece of information for the user to be able to access easily, consider repeating the information. Partial information can be dangerous and leads to issues and confusion.
- Informal Communication – This is any communication that is not made in a lasting way or requires additional context to understand. Examples of these are a design notes session, training session materials, and many emails actually as well. In this case any communication that wasn’t made in a lasting way needs to be repeated and potentially any supporting documentation may need to be rewritten.
“Don’t Repeat Yourself” is a key concept for being efficient but there is a limit to the efficiency you can gain from it. If you find yourself breaking the guidelines to be able to not duplicate something chances are you just trading efficiency today for lost efficiency down the road. You need to be prepared to repeat yourself for the sake of efficiency of others.