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.
About dandouglas
Dan Douglas - Articles on Software 
Good Day Mr. Douglas,
Once again, I enjoyed reading your views. And thanks for responding to our comments. I totally agree about the team dynamics leading into technical debt. Too often it is taken for granted that everyone is on the same page, have the same insight on it, and the knowledge to pull something off successfully. If you have a team environment then you should take advantage of it. And that doesn’t mean you have to over do it and create too much overhead that way, but use each other’s knowledge and experience. Use each other as sounding boards, give each other different perspectives on any problems. I’ve seen many junior programmers stressed out and panicking because they have already spent 30 hours on a task that should have been 20 and they still don’t know what they are doing and how to achieve the anticipated results. All they needed was 30 mins of demonstration and they were on their way to getting it done. In all of my team settings I would take the time and help others senior or junior, most of the time I was at least a little helpful, and the time that I spent with them was lost time for me, but saved them plenty of time in the end. And if I wasn’t helpful, it was because I learnt something instead, so it helped me out. I think the most efficient way of doing things is for each member of the team to have the team in mind, team goals. It sounds like a backwards thing these days, instead of looking out for each one’s self. But in the end, it promotes better architecture, better development, happier clients, and each team member gets more and better experience, and better knowledge. Sometimes that takes the company realising that a team full of intermediate-senior members getting the job done right, quickly, and efficiently is more cost productive than paying a bunch of juniors to be code monkeys for years without giving them the experience and opportunity to advance. It’s not to say they can’t hire juniors, but likely, in a proper team environment, they shouldn’t stay junior for an extensive amount of time.
What concerns me the most right now is proper architecture without technical debt for the single developer. I just want to second your thoughts. Make sure you understand the business needs up front. What are they now, what will they for sure need in the future, and are there things they may need but may not need. Start right away with the whole picture and think of how you can meet all of it. Now don’t kill yourself working out the details of something they may need in ten years and how you will be able to implement it. But certainly be aware of it. If you know what they will need in 2 years, then you can plan and have some of the framework ready to make it easier then, but certainly don’t go ahead of yourself and create too much of the framework. I keep thinking back, “Make sure you understand the business needs up front.” It needs to be clear. For you and the business. If it’s not clear and laid out, then something will go wrong, and it will end up as technical debt. The only way to know if you are over architecture or under architecture is to know the business needs. If you are unaware of that, it will always be a miss.
Steven Lane
Great comment Steve! Thanks for reading and commenting :)