More and more my focus has been turning to “How to consistently and efficiently produce good software solutions.” Identifying the core principles that make this approach or that approach work or fail in situation X.

The questions I’d like to answer include; given problem domain Y what is the best organizational structure and methodology to produce solutions? Given organizational structure Z and problem space A what is the best methodology?

 That seems to imply a nice set of core elements

1. Orgainzation
2. Methodolgy
3. Problem Domain

I started writing my about page and it turned into a post.

It stared with this:

I am a Sr Architect currently leading the QA Architecture domain for a regional insurance company. I have been writing code for about 25 years. I’ve been writing code professionally for about 15. I have been designing and creating custom enterprise automation solutions and frameworks for fortune 500 companies for about 10 years.

I also have founded or been a founding member of several small technology and consulting companies. These range from, teaching Chess to troubled youth; Restaurants (never achieved funding); Web Hosting; Custom Telecom Testing and Certification Solutions; and Online Music Sales.

And here is the post

As enterprise QA solutions (good ones at least) are tightly coupled to the SDLC I have also become involved with development process, design for test and standards.  My current beliefs on process and documentation is that there is an inverse relationship between, team connectivity and communication; and the need for formal documentation. i.e. for a small tight team, go agile, no docs all talk. for large dispersed team standards. process and docs are a must to succeed. My basic approach is to advocate lightweight and effective documentation. It should be easy to produce and contain thing people need to know. This also means that if you can’t hire a small team of quality developers to complete the project you need to spend some time thinking about how all of your docs work together.

Basically, treat you documentation and process as you would a software project, architect it and only create what you need.

Conceptually one can think of a software project as a writing exercise. Consider a project using a theoretical process in a large company:

Someone in the business gets and idea.

1. They write an email and see if people like the idea.
2. They write a charter document detailing the concept and what is in and out of scope for other business people to decide if they want it and get some idea of how much that would cost.
3. Then they bring in the BAs to write a business requirements version of the idea detailing all the things this project would do for the business
4. Next the Architecure staff writes a technical version of the idea talking about how this would work.
5. Meanwhile the BAs write a feature requirements document detailing the changes to the systems that would produce the required effects.
6. Now the development team writes a techinical document on how to write code to make the systems procude the changes the BAs have requested.
7. Finally some of the developers write code that the machines read to produce the desired effects.
8. During all of this QA is writing up notes on where and how all of these documents and code don’t agree, and making people go back and rethink and change what they wrote.

The code in effect is the final draft of a techincal paper. Formal process say all of the drafts are writen to standards by different groups. Agile process says focus on the final draft and make all of your changes there.

The basic problem all of this is addressing is that the entirety of the conceptual model for a software project quickly becomes to big for any one person to hold in their head. As soon as you need to share the model with a second person you have a problem. There are so many details and aspects of the project that interconnect and cross impact that you can’t even just put it in one document.

In agile you build a shared mindset and set of assumtions that you keep current through constant communication. Good for small teams, hard to share to larger less connected groups.

In formal proccess you publish standards and walk through a know proccess and series of documents. More overhead, but scales much better for large loosly connected groups.

Good process and architecture addresses the core issue of complexity in the conceptual model through a number of appraoches. I think Domain-Driven Design by Evans is a tour-de-force on the subject. Model clarity, separtion of domains, and the ubiquetous language to link the levels in the process stack are all wonderfull ways to make everything work much better.

More on this later.

I found out how to blog code snippets here

I was reading two good blogs about Linq to SQL and ASP.Net applications  here and here.

Based on the pattern set up by Rocky Moore (see first link) I came up with this code. Using generics and a little bit of reflection in a base class.

Here is the base class

In the partial classes created by Linq Designer here is how to add the base class

As the pattern is fixed, it is a good candidate for replace all in the partial class file.

and a usage example

This should be quite useful for detached applications.

-Chris