The Devil’s in the Details [of Software Development]

It’s always a bit upsetting when I experience that people don’t know concepts related to software development that I think are very common, because lacking knowledge about these “details” can lead to big misunderstandings.

Software Development Cat

I prefer to think that it’s my fault, our fault as an industry, not theirs fault, so here we go with a semi-random choice of fundamental concepts about software development process.

I’d like to talk about these topics distilled from my past and present experiences (yeah, more than 20 years…) in a way that’s “less about making the decisions and more about decision-making” (to cite my good friend Matt, our beloved CEO).

What I’m going to explain should be placed especially in the context of a startup, where time and resources are never enough by definition, much more than in a corporate context.

This post is directed mainly to managers and other people that have little or no experience with software production, but could also be useful to all young developers.

I’m going to be very practical, too (I’m not up to the task for theory, go find some good books about it.)

Continue reading The Devil’s in the Details [of Software Development]

A Case of Architectural Refactoring

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.

Continue reading A Case of Architectural Refactoring

The analysis phase: time to grow up?

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?

Continue reading The analysis phase: time to grow up?

Clouds Evolve: Dealing with Infrastructure Complexity

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?)

Continue reading Clouds Evolve: Dealing with Infrastructure Complexity

More on the [Computing] Clouds

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.

Continue reading More on the [Computing] Clouds

The Road to MDA

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.

Continue reading The Road to MDA

Laws of Software Development

Another interesting post about project management: Laws of Software Development.