That got your attention.... seeing that is april fool and all... ;)
Anyway, I was having some design issues the last two weeks. We do have a design around the system, high level. This is good for direction, but it proofs again that there isn't really a line to draw when it comes to proper design. By 'proper design' I mean some additional fat. The more details the better, I realise the last couple of days. Some might say 'you cant go into that much detail', but you are spending time to think of these things when you code anyway... why not do the design better, and have those issues resolved when you get to the code. For example, saying that you need validation (i.e mandatory, length) on a field doesn't really say much from a design perspective..... how will you do this validation? Will it be dynamic? Can it be configured by the client? Will it be saved as xml on the client or in the db on the server?......What design pattern might be out there to use.... How will the code transport these validations object?
Another thing I asked myself was: up to what level do you allow the architect/designer to do design? You might have a system architect who knows systems and technology.. on a high level. But you as a .Net specialist know that there are a few cool features that can be use to “design out of the box“. The arcitect only knows what .Net is and what its arcitecture consists of.... not the 'fun stuff' (if I can call it that)
So if you got that type of architect, then it means he will only design before the techology specific details.... which leaves you to complete the design anyway, either doing some additional detail design, or code away..doing some POC's, etc....
That leaves me with a question to you.... detail design using code, or follow a proper design process?
Enjoy your april fools!!!!!!!!!!!