Question

I’m presented with a need to rewrite an old legacy desktop application. It is a smallish non-Java desktop program that still supports the daily tasks of several internal user communities.

The language in which the application is both antiquated and no longer supported. I’m a junior developer, and I need to rewrite it. In order to avoid the app rewrite sinkhole, I’m planning on starting out using the existing database & data structures (there are some significant limitations, but as painful as refactoring will be, this approach will get the initial work done more quickly, and avoid a migration, both of which are key to success).

My challenge is that I’m very conflicted about the concept of Keep It Simple. I understand that it is talking about functionality, not design. But as I look to writing this app, it seems like a tremendous amount of time could be spend chasing down design patterns (I’m really struggling with dependency injection in particular) when sticking with good (but non-“Group of Four”) design could get the job done dramatically faster and simpler.

This app will grow and live for a long time, but it will never become a 4 million line enterprise behemoth, and its objects aren’t going to be used by another app (yes, I know, but what if….YAGNI!).

The question

Does KISS ever apply to architecture & design? Can the “refactor it later” rule be extended so far as to say, for example, “we’ll come back around to dependency injection later” or is the project dooming itself if it doesn’t bake in all the so-called critical framework support right away?

I want to do it “right”….but it also has to get done. If I make it too complex to finish, it’ll be a failure regardless of design.

Answer 1

I’d say KISS certainly applies to architecture and design.

Over-architecture is a common problem in my experience, and there’s a code smell that relates:

Contrived complexity

forced usage of overly complicated design patterns where simpler
design would suffice.

If the use of a more advanced design pattern, paradigm, or architecture isn’t appropriate for the scale of your project, don’t force it.

You have to weigh the potential costs for the architecture against the potential savings… but also consider what the additional time savings will be for implementing it sooner rather than later.