(English) Lightweight Microsoft.NET Process Debugging in Production Environments
Friday, August 22nd, 2008Ci spiace, ma questo articolo è disponibile soltanto in English.
Ci spiace, ma questo articolo è disponibile soltanto in English.
Some weeks ago one of my customers decided that one of its biggest ASP.NET web intranet projects needed a sort of architectural revision, mainly to support better its customers with built-in fault tolerance but also to unchain development of the various sub-projects through better separation between software modules.
When small software companies get bigger they embark on what can be a bumpy ride of change. One of those changes will probably be to do with the way they tackle the analysis phase of the software development life-cycle (SDL). Just to be clear, when I say “analysis phase”, I mean the part before coding starts i.e. requirements elicitation, analysis and system specification.
Typically (although I am sure that there are plenty of shining examples where this is not the case) small software companies with a handful of developers, where the entire SDL for a project is covered by one or two developers, tend not to have a formalised analysis phase. Why is that?
As expected, at least by me, Amazon EC2 is evolving in a more “concrete” platform good for web hosting; in fact, some time ago I received a mail from AWS announcing two new features: Elastic IP Addresses and Availability Zones (you read for sure the news also on Slashdot: Amazon EC2 Now More Ready for Application Hosting, isn’t it?)
Recently I stumbled upon a couple of articles1,2 and, remembering my experience with EC2, I discovered that utility computing was not what I was searching for: I was searching for something that helped me without adding complexity, but I was not happy with simple web hosting offers, I wanted also complete control over my infrastructure to have the technical freedom that I could need and because, when I think about my customers’ data, I trust no one.
The most expensive phase of software construction is coding and this is because it’s the less intuitive: it requires constant attention and reasoning, errors (logical or not) are difficult to spot because they are immersed in text that often is long, separated in more than one file, and not written by us.
If you ever wondered if SQL Server Profiler can influence negatively your production database servers that you watch every day with love and attentions, then stop wondering because I have an empirical proof of the fact that it causes no harm.
(more…)
Another interesting post about project management: Laws of Software Development.
Updated with Pidgin 2.0.2. You can find it here.
Another quick fix. You can find it here.