DTSTTCPW means not writing code to "future requirements" and not implementing the current requirements in a fancy-overly-complicated-cool-sure-to-impress-peers manner. I am convinced that many designs are driven by how cool they would look in a power point presentation rather than pragmatism!

Some examples of DTSTTCPW violation include writing unnecessary reusable code, writing unneeded highly decoupled code, writing code that goes above and beyond requirements, and introducing a design pattern into the code with no immediate benefit (e.g. strategy pattern with only one strategy). The remainder of this blog entry will focus on writing unnecessary reusable code as this is the most common mistake.

On a recent project, we were losing a lot of time trying to integrate with an unsupported web service. Up to seven people were involved from different sides of the planet. I started asking questions like 1) what does the web service do? 2) where does it get its data? 3) what business logic does it perform? It turns out that the web service was just executing a stored procedure and performing no business logic. Even worse, the stored procedure what local to our application's database!

Apparently the motivation was that at some point in the future other applications would potentially reuse this web service. Many readers of this might think that this is smart because someone was planning for the future. Most people have been in meetings or peer reviews where a developer is congratulated on his forward thinking for implementing a highly reusable design. Only a few years ago, I would have been impressed, too. Now, ......not so much. The reasons:

• Reusablity comes at a high cost - Implementing requirements in a way that takes into account other uses requires a lot of brainstorming and iterations to get right.
• You are not going to need the reusability anyway. Writing from experience, these sure to happen future requirements seldom happen. In lean terms, reusability provides no value to the customer.
• Added complexity - necessarily, a reusable design requires more complexity and probably more lines of code. This results in not only higher up front costs, but higher
  maintenance costs.
  

Common objections:

Yeah, but I once wrote this reusable code that was used by many other developers on a wide variety of applications!

• How many times did you write reusable code that wasn't reused?
• How much did the reusable code cost the customer?
• Did the customer benefit from the reusable code or just people within your organization, team, or department?
• Were other teams forced to use your code even though it didn't really meet their requirements?

Sometimes DTSTTCPW results in poor performance or non-functional requirements not being satisfied.

• Then you did not DTSTTCPW. Instead you DTSTT. Non-functional requirements need to be taken into account when deciding on the simplest thing that could possibly work.
  

Labels: Agile, Redpoint

# posted by Perry Hertler : 9:26 AM