New Project

We got to version 1.0 of the product I was working on, and I am really happy with where it turned out. We stabilized the product quite well and it had a really solid feature set. Now we hand it to the marketing and sales experts and see if they can make it fly in the market we built it for. If it fails, it isn't going to be engineering related, that is for sure.

Now I will lead a small very good team of 5 people including me to add interesting features to an established piece of software.

This software is known to be unstable and quite complicated. Our job will to do whatever is necessary to add hard, intricate features to the software in a way that will not break it.

This is perhaps the hardest thing you can be asked to do in computer science. It is harder (although a lot less work) than writing your own software from scratch. You have to walk into extremely unstable territory and leave the system cleaner than it was when you first got into the problem.

Basically it is going to be a learning experience all around. I am not concerned about technical difficulties of doing what we want to do. I will use this project to test run how I want a development team to work in the long run. We fortunately have a valid problem so I feel that if we can get this working well then the development team ideas I have will be somewhat validated.

Given the most ideal situation, how would you like to run a dev team? How do you want it to feel? How would you schedule work?

I like people all focusing on similar things. When we try to solve problems I want everyone, all 5 of us checking things out and working as a real team. I guess another level is managing several teams, but I am not there yet. Managing one team well is something I have never done, but I have gotten much much closer.

Because the problems we are going to solve are very difficult, I want everyone working on each large feature (called a story) at once. We are going to all analyze the problem, come up with a solution, do groundwork to get a feel for the size of the changes, and finally think of a testing or regression strategy so we know we haven't broken anything with the newer system.

Then we will divide work and move forward. But everyone will be involved in each stage of work.

1. Come up with a possible solution.
2. Check feasability and amount of code that has to change. Perhaps move back to 1.
3. Consider what functionality will be refactored/re-written and what regression testing strategy to use to ensure we don't destabilize the product.
4. Figure out testing strategy for new code.
5. Divide up work and split into pairs or singles depending on problem.

I guess I just really want everyone on the same page. I want people to share and understand whatever overarching vision we come up with and also share in the considerations necessary to keep the product working.

More than anything else, I don't want people to work in their small corner. I have seen that work and I know that a few members of this team would happily do that but I just don't feel that model of development is how good software is done. I think it takes really open design process and lots of shared knowledge.

Anyway, what I really really want is everyone fully engaged and working with each other. I don't care what system is used, good development takes a serious team effort. I believe that is really what is lacking from the current processes that I look at; not enough good team work at the architectural and very abstract level.

Chris