Architecture

• Dec 5 2009 - build it (so it's easy) and they will come (make the right decision) ... One of the biggest lessons I think I’ve learned over the past few years is that you have to be very careful with what you make easy to do in a software system. When you are working within a preexisting system, it is very hard to work effectively outside the bounds of that system. Whether you are limited by time constraints, peer pressure, political decisions or just pure technical inertia, those early/legacy decisions in a system will have long reaching impacts on the decisions of those who follow.
• Sep 1 2009 - lessons learned from online gambling - predicting scalability ... I work with someone who has spent a few years working for an online poker company who shall remain nameless. This company was responsible for a poker platform that supported both their own branded poker offering as well as being an engine for other companies who would layer on their branding. My colleague played an important role in taking their fairly well built existing system from thousands of users to tens of thousands of users, and in the process exposing a large handful of very deep bugs, some of which were core design issues.
• Sep 1 2009 - sometimes it's helpful to think about what NOT to do ... Came across this list of “anti-patterns” on wikipedia tonight. I’m tempted just to copy and paste the contents here but that would make me feel dirty. Definitely a good list though and something worth reminding ourselves of every once in a while when thinking about the systems we build. http://en.wikipedia.org/wiki/Anti-pattern
• May 8 2009 - Simple Extensibility in .NET ... I’ve used this approach a few times when I essentially need a really simple plugin / provider model within my applications so I thought I’d jot down the relevant details here for posterity using an old project for adding post commit hooks to subversion. Consider this a somewhat simplistic approach, not suitable for production code without a bit more plumbing. If you are going all out and need true add-in’s for your .
• Sep 6 2008 - frequent beachballs in mac os x caused by bad fonts ... I’ve been testing the latest nightly builds of firefox 3.1 over the past few days and while generally impressed with the performance improvements in javascript was quite disapointed that it was causing my iMac to go into frequent hangs where I would see the spinning beachball of death for many seconds before I could continue working again. It became bad enough that I finally had to ditch my firefox testing efforts.
• Jul 21 2008 - Documenting architecture ... One of my side projects at work right now is documenting the architecture of a product that has already been built but will be going through a re-architecting with a focus on a more robust schema and applying some of the learning we’ve gone through in discovering exactly how our product is being used and ways in which our users want to extend the platform. SaaS and SOA are two good buzz words we’ll be throwing around a lot, although to be honest we’ve been in the SaaS model for years now, just not following all of the best practises.
• Jul 17 2008 - Microsoft's add-in framework and the need for diligence ... We’ve recently put Microsoft’s managed add-in framework (part of .NET 3.5) into very effective use building a plug-in system for a large asp.net application at work. Essentially the framework in place allows other developers (and our own team for out of stream releases) to develop new functionality for our platform that runs the entire life-cycle for a given widget. In our case for this particular widget we’re talking about plugins being responsible for up to 4 asp.
• Mar 30 2008 - On the need for re-architecting ... I have been grappling with the concept of a rewrite of a relatively successful software product that I’ve been involved with since start-up mode. In truth I was googling for compelling stories about why NOT to disappear for a year to do a complete re-engineering of your product (ala Netscape). Mostly because I’m concerned about the size of the effort and the resources we have to pull it off. Instead came across this article, espousing the need to fire all your developers!