It is widely believed that most problems in computing can be solved using a combination of finite state machine, recursion, iteration, lookup. The efficient solutions use a minimal combination of these. This broad statement holds good if you are in a homogeneous world i.e. ignore the latency issues posed by artifacts (databases/webservices/filesystems/memory/microprocessors). Homogeneous entities would've simplified the life of developers and reduced the need for the like of performance engineers/profilers. In essence there wouldn't be a need for enterprise architects!. Thankfully, we live in a eco-system with non-homogeneous entities, my senior architect friends are even more thankful ;)
While the job of a developer is to come up with a solution that is of the least complexity (as defined in first paragraph); It may not result in a good design. A really good design is open for extension and closed for change. Extension here means new requirements and modification requests, change implies unwanted hacks/shortcuts that result in spaghetti code. Good design is contract driven, minimizes the number of interfaces, reduces the state visibility (and thus dependencies, the idea is that you cann't litter what you cann't see!). Designers are so used to the GOF patterns and averse to complexity, that they scream at any interface that forces them to scratch their head. You normally scratch your head when you see a brilliant snippet or murky monster, the later being true for the most part.
The point of this post, is not to reveal the obvious, but explain those rare encounters where you have seen a solution that is worth being marked as a new design pattern. I dont' have an exact term to define this experience, but I will try to describe the feeling. At first you realize that it would work, but think it is so odd that it looks like a ugly duckling. Then think of improving it, and realize that you cann't! there is nothing to remove from it, and whatever you add makes you look like a buffoon. You explain this to your peers and they go through the same phase, congrats you've a graceful swan not a duck. More on such experience in the next post
While the job of a developer is to come up with a solution that is of the least complexity (as defined in first paragraph); It may not result in a good design. A really good design is open for extension and closed for change. Extension here means new requirements and modification requests, change implies unwanted hacks/shortcuts that result in spaghetti code. Good design is contract driven, minimizes the number of interfaces, reduces the state visibility (and thus dependencies, the idea is that you cann't litter what you cann't see!). Designers are so used to the GOF patterns and averse to complexity, that they scream at any interface that forces them to scratch their head. You normally scratch your head when you see a brilliant snippet or murky monster, the later being true for the most part.
The point of this post, is not to reveal the obvious, but explain those rare encounters where you have seen a solution that is worth being marked as a new design pattern. I dont' have an exact term to define this experience, but I will try to describe the feeling. At first you realize that it would work, but think it is so odd that it looks like a ugly duckling. Then think of improving it, and realize that you cann't! there is nothing to remove from it, and whatever you add makes you look like a buffoon. You explain this to your peers and they go through the same phase, congrats you've a graceful swan not a duck. More on such experience in the next post
Posts
