Getting Closer To The Fine Line In Software
July 25, 2011 2 Comments
My latest blog post touched on the fine line between no architecture and over architecture in software. I talked a lot about technical debt and why it’s bad. I got some feedback and some were wondering exactly how do you find that fine line, so here are some suggestions for improving in order to get closer to that fine line.
There are a lot of factors to look at to find that ‘fine line’ between over architecture and no architecture. If we are looking at a team, some questions to ask might be – How well is the team working together? What are the team dynamics like? Solid trust within the team? Is the team focused on team goals and team wins or is it more or less individuals on the team looking more for personal glory or wins as a higher priority than the teams goals? Or, does the team even have any team goals – is it strictly individual goals that are being strived for? Are people afraid of their superiors and feel free to provide their own opinion even if it seems constructive in order to better achieve the right team solution?
Asking these questions can help narrow down if there are general team problems that are contributing to the software problems…
If it’s a team problem, I’d suggest starting improvements at that level. Strategize some team building sessions, meet weekly to discuss and resolve any issues from the prior week (in agile environments, this would be done at the retrospective at the end of each sprint/iteration.). Get the team working together, setting goals together, and build a culture where the team is working together all the time. People aren’t afraid to speak up and everybody is working together to improve because the only goals that are important are the team goals. If the team wins, everybody wins, if the team loses everybody loses.
The teams that are the most successful are the teams that work well together. This creates a much bigger win than individuals working in silos would be able to do. The result in software is much much improved software and less technical debt. The same could be said for a sports team or a team of any nature.
Ok, so that’s some basics around team stuff and sorting out team dysfunction.
Once that is sorted out you need to collectively create goals. With mutual respect in place among team members, better architectural discussions can be had with everybody speaking up about the architecture and coding standards. And do some pair programming as well :)…
Some say code reviews are ineffective and don’t work. They do work, I’ve seen them work. So, try code reviews. A great way for the entire team to review and interact on existing code and talk about refactoring for future software updates.
Understand the business requirements as best as you can up front, ask the right questions, and get everyone on board with where the software is going.
One thing I’ve always done when thinking about what to include in an architecture is come up with a scenario where the said architecture or pattern will help solve a problem (problems could be barriers to implementation, complexity concerns, business use cases, etc) and think about how the architecture lends itself to that. Look at the cost of implementing and maintaining the architecture and also the learning curve required versus the added value you are providing. Sometimes, I’ll only partly implement a pattern or architecture just so it’s there and if I really need to fully implement it in the future, the refactoring is simplified to make it so. This is to have a minimal affect on maintainability and over architecture as it creates a scenario where you can do the architecture up later when needed without mega refactoring.
Also – try not to create lists, weighting scales, or pro and con arguments on paper or a white board in coming up with your design. If you are solo just take some time out and really think about it, and talk to colleagues about it. In a team, get the team together and pound it out. Don’t analyze it to death though, it’s not worth the cost of that ;)
Have the architects create a vision and strategy and then discuss it with the entire team to come up with something even better. Implement it and continually review and adapt it as necessary. Don’t have someone make an individual decision about an architecture or pattern and then leave it to the other developers to have to deal with it and the technical debt it could create. Always get team buy in for technical strategy.
Someone at the Senior Architect level, by my standard, should surely know how to listen and communicate with the developers on these types of decisions in order to get the best possible outcome.