I've worked in many different software development shops. I've worked for companies with 2 employees to companies with 200,000 employees, and everyone has "their way". I wanted to talk a little bit about "our way" because it is most certainly "the best" ;-)

A Little Background...The Chaos Theory Report

If you haven't read it, go check it out. The Standish Group, in conjunction with SEI and Carnegie-Mellon put together this research paper back in the mid 1990s. The basic question is "why do so many software projects fail?" The findings were ... allow me to summarize thousands of hours of work in half of a sentence ... we allow too much scope creep, and we don't learn from our mistakes.

Duh.

What Can We Do To Build Our Software Better?

An engineer once said, "let's first build a process".

What Is The Purpose of a Software Development Methodology?

There are three things a process will attempt to make better:

Quality of the deliverable.

Cost of the deliverable.

Timeliness of the deliverable.

Don't kid yourself. This is really what it is all about. It's not about a SCM or use cases; It's not about aggregations or associations. It's about quality, cost and time. And not necessarily in that order.

In the United States, "quality is job one". We never release any software that isn't completely bug free and certified to be of the highest quality. Wait, that's a lie. Well, actually as a society, cost is what we're most concerned with. We build the most cost effective software solutions in the entire world without fail. Wait, that doesn't sound right either. Perhaps, time is the most important metric that we as software designers and developers are graded against. Is that possible? Have you ever been asked to meet an unreasonable deadline where there was little or no regard for the cost to do so, or if the final product wasn't 100% ready for primetime? You bet you have. We all have. We are a time-driven society. And we regularly sacrifice quality and cost in order to meet the timelines of our corporate leaders and business partners.

A Software Development Methodology's Purpose Is To Enhance These Aspects ... And That's It!

A methodology is nothing more than a road map. Who does what when and based on what tolerances and thresholds. The underlying reason for leveraging a process is to enhance the likelihood that the deliverable having sufficient quality, after having been constructed within budgetary constraints and put into production on time with regards to the business demands. And really not anything else.

At Artis IT We Are Not Purists...We Are Problem Solvers

And problem solvers use the best tools that they have at their disposal to get the job done. We try to do what makes sense...and sometimes that means taking a little from here and a little from there. I am not a software development methodology inventor, but I am an engineer (mechanical). What I have seen in my professional experience is that there is no "silver bullet". There is no panacea. The folks at Rational will probably disagree with me. Much like the proponents of XP or the Agile method. Personally, I prefer the old school teachings of Sir Isaac Newton and his Scientific Method. Problem, hypothesis, procedure, data, results, conclusion...you do remember 7th grade chemistry, right?. The truth is, they are all good, but they also have their limitations. I think it is important to remember Isaac wasn't trying to sell you a CASE tool for $10K.

Use Case Centric Approach With Iterative Release Cycles (Monthly Sprints)

At Artis IT, we typically build software using object oriented technologies like Java and C#/.NET. We especially love to build web-based software and intranet applications. We feel these technology stacks allow us to program the way humans think. We like that since we are all humans at Artis IT. Additionally, we attempt to build reusable modules just like the books say we should ;-)

Taken from the Agile world, we employ the concept of a "monthly sprint". All of our project operate on a monthly release cycle. We implement new functionality into all of our systems every month. These new capabilities come in the form of use cases (or in some cases, enhancements to existing use cases). We are fond of the templates the smart guys at Rational put together. We have a few of our own as well. Also, another Agile-esque concept we embrace is the idea of a scrum. Everyday, our entire team participates in a 15 minute standing meeting in which we lay out what we did since our last scrum, what we didn't get done (and why), and what we're going to get done before our next scrum. We've found these standing meetings enhance communication and help provide minor course adjustments during the monthly sprint. Every member of our team knows what they are responsible for accomplishing today...and how that correlates to the medium sized picture goal of the monthly release. Finally, we also embrace the concept of a "feedback loop". We believe that there will be issues and alterations to the course will be necessary. That is, we embrace the likelihood that something will not work out just as expected. Much like the analogy of the bridge falling down in the Chaos Report, we want to know why something went wrong...and then not do that again.

We Use Magic For The Rest!

Obviously, there is much more involved than just saying we are going to do a deployment of new functionality into a production environment once a month. There many critical details surrounding complex topics like business rules conception and analysis, architecture and design, testing and quality assurance. What we've found is that it helps to have passionate experts as part of your team. We believe that we've assembled a team of those.

If your interested in hearing more about our methodology, please contact us. Additionally, if you think you might enjoy working with our team, check out the Careers section of the website.