May 2008 - Posts

• Retaining Good People

  This is largely common sense, but I'd bet there's a large number of IT shops out there that haven't picked up on this yet. Do you want to keep the best people on your staff? Make sure you have career paths for them.  If there aren't clear avenues for people to be promoted or advance, it means they will be forced to look outside your organization to move up.  Those who are talented or work agressively to advance will be forced to leave as they become more skilled.  If you are in an industry where prior domain knowledge is prized during the hiring process, that also means you will likely lose them to your competitor.  Ouch. Posted May 29 2008, 09:04 PM by hoffe with 5 comment(s)

• Estimating System Load

  One of the initial steps that every non-trivial project should go through revolves around determining system usage requirements. Here's a no-nonsense method for tackling this issue head-on. 1. Anticipate Usage and Usage Patterns A prudent developer or architect will find out who the end user will be.  He will also find out the anticipated numbers of end users that will be accessing the system.  In addition, he will look at the anticipated usage pattern to look for things like spikes (ie..all users log into the app at 8am on Monday..or users only log in once per year).  Note: Don't forget to include integrated applications in the system usage numbers.  They generate load just like human end users. 2. Estimate Future Usage Assuming the number of end users isn't fixed over time, you should also estimate future growth.  If the application will be used in house, ask what the hiring trend will look like for the next year.  If this is a web startup, you might look at future revenue (ie..$10/user per month) and determine what an acceptable cap for the system will be (1000 users = $10k/month).  Spend time talking with the customer and find out what is acceptable and within reason.  They will appreciate you setting realistic expectations for them. Also take time to compare how the numbers change.  Some systems (ie..internal systems) may exhibit growth in usage that's linear (ie..adding 5 additional users per year).  Other applications may experience exponential growth (ie..the next hot social networking application).  It's important to be able to recognize those exponential growth apps, as extra care will be needed. 3.  Calculate Anticipated Load Taking your usage figures, try and give a rough estimate as to the number of calls/requests per second the numbers translate into.  If this were an HR web app and there are 35 people in HR (with no anticipated hiring in the next year), you might estimate the number of calls per second for the entire department.  35 people * 3 seconds between clicks = ~12 requests per second 4.  Include a Margin of Safety Taking load estimates and multiplying by 10 will give you a nice cushion for error in your estimates.  In the fictitious example above, we need to validate that our system will handle at least 120 requests per second. 5.  Sanity Check Your Architecture The initial development done on any system should be a threading of the architecture.  This means wiring each piece of the entire system together, from UI to database and everything between.  This step allows you to vet the high level design of the system.  It also allows you to sanity check your baseline architecture against the usage requirements.  Can the technology you've chosen and the deployment you've designed handle the anticipated load?  If not, it's better to find out now, rather than develop the app and find out during the initial deployment. Posted May 22 2008, 12:27 AM by hoffe with 4 comment(s)

• And You Thought Your Deployments Were Tough

  Did you know: eBay deploys a new release every 2 weeks They add roughly 100 KLOC per week to the codebase That should be a little extra motivation to work on removing the waste and increasing the flow of getting your application out the door.  If they can do it with a 6 million line codebase, why can't you on your codebase (which is likely trivial in comparison). Source:  The eBay Architecture (circa Nov 2006) Posted May 21 2008, 10:50 PM by hoffe with 3 comment(s)

• On Comparing Current Tools to Futureware

  I'm going to take a quote from Daniel Simmons on why we should use the Entity Framework. I'm not specifically interested in his comparison with NHibernate because I think the following is true of many current O/RMs (whatever your personal flavor happens to be).  I am, however, going to quote it because it caught my attention. The big difference between the EF and nHibernate is around the Entity Data Model (EDM) and the long-term vision for the data platform we are building around it. The biggest problem with comparisons like this is that you can't compare unwritten software with something that's already in production today.  The false assumption underlying this is that the current breed of O/RMs will stand still while Microsoft magically comes from behind to deliver an innovative platform.  It just doesn't happen like that. So how does the EF differentiate from the current breed of O/RMs?  Apparently, it doesn't.  That's slated for the next version. Here are a few other reactions that I agree with, that hit my RSS reader today: Why use the Entity Framework? Yeah, why exactly? Reaction from Jeremy Miller Why EF? More Entity Framework Thoughts EF Long Term Plans Entity Framework: Our Albatross Rewriting the Entity Framework Source Control Support In short, the Entity Framework is a 1.0 release.  Expect from that what you will. Let's just hope that the next version (or two) will hit somewhere near the mark--although I do have really big concerns about some of the design decisions they are pushing (such as reusing the models all over the place).  It sounds like an expensive and delicate design to maintain.  Smearing any kind of structure or model (data, object, or conceptual) makes change to that model quite a bit more expensive. That is, in fact, software design 101.  David Parnas was writing about it all the way back in 1972. Long-term we are working to build EDM awareness into a variety of other Microsoft products so that if you have an Entity Data Model, you should be able to automatically create REST-oriented web services over that model (ADO.Net Data Services aka Astoria), write reports against that model (Reporting Services), synchronize data between a server and an offline client store where the data is moved atomically as entities even if those entities draw from multiple database tables on the server, create workflows from entity-aware building blocks, etc. etc While it often seems like a good idea to expose things like entities to the outside world (it's reuse, right?).  The illusion quickly gets shattered when you start looking at how things will change in the future.  Sharing data models usually means spreading the associated logic around.  Spreading logic around means duplication.  Duplication is costly to maintain.  It also has very real coupling issues.  Also, if adding a new field to the Customer entity requires many changes (both in your app and in your consumer's apps), you've done a piss poor job of design (think: sharing internal models across service boundaries). But not only that, but I find that this type of thinking leads straight into CRUD. I'm going to stop here because I'm quickly winding my way into a design death spiral.  And I think you get my point. Posted May 19 2008, 11:55 PM by hoffe with 5 comment(s)

• Don't Do That

  Over lunch today, I learned about one of the company's recent acquisitions.  Here's the short of it: The production system has between 6k-7k different Access databases (databases, not tables) Since the app creates new databases on the fly, no one is sure which are production dbs Don't ever do that.  Please.  And no, I couldn't make this one up even if I tried. ;-) Posted May 08 2008, 11:18 PM by hoffe with 9 comment(s)

• A Very Poor Object Model Is Really No Object Model At All

  First let me say that I've met Keith personally, and he's a really cool guy.  Cool enough in fact, that he's on my RSS subscription list. I'd consider him a friend.  :-) This is my response to his recent post, How To Not Screw Up Your Application Object Model.  I'll also point to Arnon's reaction. Exhibit A: This is a very, very poor object model.  It's a very poor object model even if it perfectly represents the business requirements. I'm going to nickname this the "college freshman" object model, and we all know how useful college freshmen are in the real world (and just how much they have to learn before they become useful).  In short, never do this--again, even if it perfectly represents your business problem (which it won't). I'll also repeat what Arnon said.  In a nutshell, don't use a bulldozer where a simple shovel will do.  Building an app for a vet is a good candidate for CRUD and Microsoft Access.  Don't overcomplicate your solution. Also, if you are developing outside the guidance and expertise of the customer, you greatly increase your chances of failure and waste.  Don't do that.  It's irresponsible and foolish. I'd also like to point out that this object model is driven by the C++ object model thinking of yesterday.  We've learned a lot since the 70's and 80's, and that includes how to do objects. I'll point out two very important facts that are rather obvious: We don't have multiple inheritance in C# or VB.NET.  That greatly affects how we do OOP. Inheritance is a very fragile.  99% of the time it's the wrong tool to use (as this diagram elegantly illustrates) Luckily, we've learned a lot in the past 10 years and evolved our design techniques since then. Inheritance is the old stuff.  Composition is the new stuff.  We've learned about the fragile base class problem and moved on.  A solution using composition (instead of inheritance) yields way more flexibility and is much more resilient to change (when used properly).  Where inheritance represents the relationship with the most coupling between two classes, composition allows us to freely decouple two (or more) classes. Is bad OOP really bad OOP or is it just not OOP at all? If you've implemented a deep type hierarchy in your .NET app while trying to build an "object model", you've sorely misunderstood how to apply OOP in .NET. In conclusion, I'd like to challenge Keith to write a new post on the following: The reason is because we have been beat to death with OOP principles. I'd be curious as to what principles you are referring to.  I get the feeling that the OOP principles you are referring to are completely different from the ones I follow.  I'd love to carry this discussion further. Posted May 04 2008, 09:59 PM by hoffe with 10 comment(s)

• A Reader Challenge

  This is a simple challenge.  I want you to figure this out for yourself.  It's an important step I think every developer needs to take for him/herself. Also, please don't give any direct answers in the comments or I will delete them. Non-answer comments are perfectly acceptable.  :-) Without further ado, can you please give a simple definition and compare the following: Procedural Code Object-based Code Object-oriented Code In particular, what's the difference between object-based code and object-oriented code?  I'll give you a clue, it doesn't particularly have anything to do with inheritance. You might find these concepts in a few books.  I'll drop a couple references here. C++ Primer (Parts 3, 4, and 5) Object-Oriented Design Heuristics Finally, I'll leave you with a slightly harder teaser problem.  What's an "Object Role"? If you are unsure, feel free to drop me an email, and I'll steer you in the right direction (evanatevanhoffdotcom).  I'm not recommending those books for starters (although I'm sure they are great books). Posted May 04 2008, 08:46 PM by hoffe with 2 comment(s)