That’s the big question, any time someone is starting a blog. I know there is something that I want to say; knowledge that I can provide to help someone solve their programming challenges. It’s just a matter of gaining the discipline to consistently post something.

I want to talk about the issues I see in our programming shop at work, what is causing them, and how I think I can help fix them. I want to explore ideas about meta-programming tools (software factories, code generators) that help to leverage the knowledge of a SME and distribute it to the entire team. I want a place to just talk about a cool tool that I’ve found, or a bit of code that I might have written.

By title, I’m a Sr. Software Developer at Compassion International. In actuality, I’m moving (unofficially) into the role of a Solutions Architect. There are a few of us on the development team with the temperament and ability to look at the bigger picture, beyond the confines of the current project, and try to envision making all this “stuff” work together, and work well.

Compassion is a Christ-centered organization ministering to children in poverty throughout the world. That fact makes it different than doing the same job for a bank or financial center. We’re writing the same type of code, same kinds of applications, but at the end of it, I can look back and say that I am truly making a difference in the world, both today and in the future. We need to be effective with what we create; a failed or abandoned project is funding that could have gone to another effort within Compassion. There is a lot of self-imposed pressure applied.

I am currently assigned to two projects: CSP and CIV (we love acronyms at Compassion). The CSP project is phase 2 out of about five, and is just about finished with refining requirements and beginning to write code. My role on this team has been different for me. This is the first time that I’ve worked on a team and purposely not written any code. I feel like I can be more effective here by providing design guidance and helping the other team members to get their heads into the problem and express the ideas that I have come up with. We’re also trying to follow a Scrum-like process, which is new for most of us on this team. Our biggest challenge at the moment is in defining our interim deliverables (what will we demo at the end of each two-week sprint). I think that is going to change in the near future. Most of the uncertainty in what we are building has been driven out (or at least exposed to the light so that we can stab at it!) and the project manager is going to help us refine our backlog of features and get it broken into tasks and prioritized. The customers on this project are not really into the whole Scrum idea, so there is a lot of us pushing things to the customer and getting them to say “Yeah, looks good,” or “What were you thinking?!” Either one works for me, as it gets discussion going between the development team and the business unit that will ultimately have to live with the code.

The second project is CIV. It is going through changes at the moment, and building steam. We were initially looking at an ASP to provide most of the functionality, supplementing it where necessary with custom code through web services the ASP provides. The problem (or opportunity, pick your side of the coin) is that CIV shares a lot of processes and ideas with the CSP project. The project management group has finally seen that, and we are going to be building CIV in the footsteps of CSP. Right now, I’m going back and reviewing the analysis and process diagramming that was created for CSP and identifying similarities and differences. I expect that when we finally get to a place to code, it will involve a lot of work refactoring what was done for CSP and making it more general in the process of adding support for CIV. Overall, this is a good goal, but something that is difficult to explain to management, or to predict how long/how much to do it.

So, expect plenty of talk about issues that crop up on the teams, ideas about how to make the teams more effective, and how to distribute the knowledge that individual programmers have in their heads to the entire department.