This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: Mistake #1
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
I haven't yet found a mistake of mine that I want to publish, but it just so happens that I came across someone else's ( luckily ).
On Udi Dahan's Projects you can find information about the projects that I've currently got underway - 5 ( +1 that I'll have to take on later ).
On one of the projects, Accounting System, I am charged with taking a project that's finished development ~95% and taking it to production. The developer took me through the system, and I realized that this was not the architecture that I had envisioned when told: "This is a good system. Well architected, stored procedures, and C# code that calls it. ASP.NET pages using code-behind. Its practically finished."
You can see what kind of monster I've inherited here.
To all you DBAs out there who want to develop systems, I tell you this: Do NOT put all the system into the database just because you can ! Even the dreaded "3-tier architecture" is better than that.
Just so the rest of you get an idea of what I'm talking about, think about putting all possible logic into the DB. Calling a stored procedure is all you ever do from the UI besides basic GUI event handling stuff. The SP then does everything - checks business rules, sends email, calls webservices, performs calculations - you name it.
And WHY did they do this ?! So that they could change the functionality of the system without recompiling it ! Let's see, toss out all the *abilities ( maintainability and all the others ) , get ability to change system without recompile. Hmm... That's like trading diamonds for glass.
Now, here's the best part: For the project to be profitable, I'll have to work by the same conventions ! ugghh...
Final thought: "It works" isn't an excuse.
Well, I guess that my mistake in this whole process was assuming. Assuming that what I consider well architected, and what someone else considers well architected are two different things. Or, more generally, miscommunication. Even though I was told what to expect "Well architected, stored procedures, and C# code that calls it...", I didn't verify what this exactly meant. And even worse - I gave an estimate based on my assumption.
Lesson to be learned ( for me - and I'm only writing this so that I can berate myself more harshly the NEXT time it'll happen ): Actively search for the hidden assumptions that I make when listening to someone. Make them explicit. Verify them with the speaker.
Final note: although I've heard this piece of advice many times before, and, like most things, is just common sense, it wasn't REAL until it happened to me.
Previous Topic
