Why make things consistent?
Things should be consistent. When we're talking about I.T. artefacts (how we build databases, how we structure database tables, how we write code, etc etc) we should build them consistently.
This ought to be obvious. But wherever I go, I see quite the opposite. Many software applications, or I.T. departments, or enterprises, are basically a collection of various artefacts, all of which have been built INCONSISTENTLY. And then people wonder why it's so hard to manage all this.
The reasons things become inconsistent are many. Here are a few examples:
- Many different developers looking at the same application over time, but not paying any attention to existing patterns. In other words, for whatever reason (maybe they haven't been trained to see in this way), they don't actually SEE the pre-existing patterns.
- Developers think they have a better way of doing something so they just start doing things their way, without any regard for pre-existing patterns. In other words, they see the patterns, but they don't care. They don't like the patterns. They think their patterns are better. So they introduce new patterns. Now you've got at least TWO sets of patterns.
Now multiply this by the number of developers who don't see, then add that to, then multiply by, the number of developers who don't care.
What you end up with is a mess. It contributes to unwanted technical debt. Somebody's going to pay that debt someday, one way or another.
Why make things consistent?
When you make things consistent, it reduces maintenance cost and effort because
- you don't have to think about certain things.
- you don't have to wonder, is this one using method A or method B?
- you can apply consistent methodologies to manipulating these artefacts.
- those methodologies will be guaranteed to work because you know the structures are consistent.
Here's an example.
If you're building database tables, let's say you want to know when a record was created; who created it; when it was last modified; and maybe a timestamp. Why not make that consistent across every table in the database?
Why would anyone in their right mind want to make it different from one table to another? And yet, I see this all the time. The reason is, nobody has taken responsibility for ensuring they're consistent. It's not going to happen by accident. Somebody needs to own it. Maybe that somebody is you.
Over time, different developers create tables; some happen manually; some are scripted; nobody's made the methodology consistent, so stuff evolves organically over time. Then somebody comes along and tries to make sense of it all, and what they find is essentially an unmaintainable mess.
Again this ought to be obvious. But it just isn't, to some folks. This is for them. Maybe one of them will run across this one day, and it might spur them to say, hey, maybe I can make MY stuff consistent too! :-D
This ought to be obvious. But wherever I go, I see quite the opposite. Many software applications, or I.T. departments, or enterprises, are basically a collection of various artefacts, all of which have been built INCONSISTENTLY. And then people wonder why it's so hard to manage all this.
The reasons things become inconsistent are many. Here are a few examples:
- Many different developers looking at the same application over time, but not paying any attention to existing patterns. In other words, for whatever reason (maybe they haven't been trained to see in this way), they don't actually SEE the pre-existing patterns.
- Developers think they have a better way of doing something so they just start doing things their way, without any regard for pre-existing patterns. In other words, they see the patterns, but they don't care. They don't like the patterns. They think their patterns are better. So they introduce new patterns. Now you've got at least TWO sets of patterns.
Now multiply this by the number of developers who don't see, then add that to, then multiply by, the number of developers who don't care.
What you end up with is a mess. It contributes to unwanted technical debt. Somebody's going to pay that debt someday, one way or another.
Why make things consistent?
When you make things consistent, it reduces maintenance cost and effort because
- you don't have to think about certain things.
- you don't have to wonder, is this one using method A or method B?
- you can apply consistent methodologies to manipulating these artefacts.
- those methodologies will be guaranteed to work because you know the structures are consistent.
Here's an example.
If you're building database tables, let's say you want to know when a record was created; who created it; when it was last modified; and maybe a timestamp. Why not make that consistent across every table in the database?
Why would anyone in their right mind want to make it different from one table to another? And yet, I see this all the time. The reason is, nobody has taken responsibility for ensuring they're consistent. It's not going to happen by accident. Somebody needs to own it. Maybe that somebody is you.
Over time, different developers create tables; some happen manually; some are scripted; nobody's made the methodology consistent, so stuff evolves organically over time. Then somebody comes along and tries to make sense of it all, and what they find is essentially an unmaintainable mess.
Again this ought to be obvious. But it just isn't, to some folks. This is for them. Maybe one of them will run across this one day, and it might spur them to say, hey, maybe I can make MY stuff consistent too! :-D
Comments
Post a Comment