As architect, I'm constantly asking why. Why do we need this system? Why is that feature important? Interestingly, when I work with a new client, the why of things is normally not included in the documentation or project artifacts.
What folks don't seem to understand is that project documentation serves two primary functions. One, to document what has been done and two, to help educate new team members on WHY things have been done.
Over the years, I have learned that there are really no right choices. Everything is a tradeoff. When a client asks, "is this the right design?" Or "is this the best practice?" I always cringe a bit inside. In reality, there are tons of bad designs and bad choices you can make but there isn't one single right answer.
So, focus on the why when considering a new design. The why will inevitably lead to the what and then to the how.
No comments:
Post a Comment