Software Best Practices

We are at the design phase of a new project. The project is staffed by developers who are not very familiar with newer maintainability concepts from refactoring. The most senior staff has a heavy background in C and prefers low level C constructs over C++ standard library classes.

While fleshing out an interface for a particular method, I noticed that the parameters for that method does not seem stable as they were figuring out several flags to add to the parameter. And so I proposed to use the commonly used refactoring technique of putting the unstable parameter inside a class wrapper. Hence the new class would handle the housekeeping related to flags and the data. When I was explaining the benefits of this to my colleagues I somehow fell flat, as they were not familiar with the concept I was introducing. They were explaining based on experience that the initial approach was enough, however I have also been using that technique for quite some time now and found it to be very beneficial.

Based from this story, I would know the best way of explaining new concepts to colleagues and selling them to the idea without pointing to a book or a website.

That is common problem, and I have experienced some. This is like a battle between procedural programming and object-oriented programming (in this case C vs C++, and to some people, it's just like a battle between speed and maintanability. Who will win? Well, it's not a win or lose problem since every project has its own concern (speed over maintanability, or vice versa). I have trained OOP to some programmers who never use it before, and it could take a whole day long to explain the fundamental concept, since many of them looked like newbies in programming when they faced new paradigm, even if they have coded for years. So, I think we have to explain it in a way that they do not feel like newbies, and the most important is, not to show that OOP wins over procedural since it's not the whole truth and nobody wants to feel like a loser. Just focus on the features of the new concept, and be fair also to its weaknesses. And perhaps your project need also documented standard development guide for developers to follow in designing and writing the codes.

 

When you are explaining a new concept, don't explain it as part of your comment on the code. You can arrange weekly or monthly sessions to the team to explain to them new concepts that affect the current project. You can even start those seminars before the project start.

The idea is that having a dedicated seminar can give you high acceptance for new concepts since the meaning of a dedicated seminar is "I am coming to explain new things that you don't know", while discussing the concept as a part of a code review can seem as another opinion that they can accept or reject. Also having a dedicated session can give you the opportunity to use a lot of examples that they can think of separately instead of thinking of the new concept in the shades of the current application with lots of things struggling in their minds such as requirements, design, algorithms, etc.

Also the person who tells the new concept can make a difference in the level of acceptance of these concepts. If you are new to the company or a junior ( and this doesn't mean that you are inefficient) then older people may not accept notes from you - I know this is not a healthy sign, but this is how some people may behave. If you feel that this is a reason why they refuse your comments and opinion, try to find  someone who you think they will accept his advice and explain the concept to him and ask him to move it to others.

In addition to what has been said, consider the possibility that they actually have an important design perspective. Remember that object-oriented design –or whichever buzzword- is not synonymous of good design. Each design decision has a context attached to it.

Yes I know what you mean about pushing with the latest technology buzzword because it promises good design.  However this is not really the point in case.  What I was really trying to do is introduce a new concept to improve the design.  Take into consideration that we were at the design phase and in this case I was suggesting an improvement over a typical design flaw of putting all the flags and other variables as arguments into a method.  However this is a case of lack of shared knowledge in terms of new design concepts.  What I was really trying to know is what's the best way of discussing a new concept in a design meeting. 

In the scenario I discussed I tried enumerating in terms of pros and cons however the real benefit of Passing a whole object rather than specific fields is more of interface stability and somehow I couldn't make them see the importance of having a stable interface.  I successfully sold the idea to them after discussing practical applications.  However it took too much time and effort and much debating and their concerns over performance far outweighed my concern over stable interface and ease of use.  So I thought of a more concrete class to justify the object parameter, that sort of worked.  I guess what he was looking for was a practical application for the interface change, I was going for evolutionary changes that would later flesh out into a more concrete class concept later and rename the class to the concept it represents.  One basic problem is I based my initial suggestion on why the change needs to be done on the theoretical value of the change, however I could not go into the practical value until much later when everything clicked in my mind.  Up to this point I wouldn't know how I would convince them to prefer a stable interface over their initial approach, the reason is much too ingrained in theory.

 

I like the ideas of keeping separate seminars/sessions. That should be done, IMO, regardless of the issue here.

I have also found out that to convince people you often have to give practical code examples to justify your point of view. It's very hard to argue with actual real code. It's not abstract like a claim that something should be done in some way. I am not sure people can really understand the point you are making without having the time to think it over in their rooms with a piece of code staring back at them. This is oneway how meetings are very limited, when we're talking about software design. It's a hostile environment for deep thought which is often required to make good design choices - or to even really understand the proposals that were made.

When it comes C/C++, I would have taken the route to remind them that there isn't any real difference in structs and classes, as this could have been a way to convince old-school C - developers to see the value of using a class somewhere.

You need to get their buy in to the concept you are trying to get across. Just arranging a seminar etc won't do it - they won't have any personal involvement in it. Just telling them that this way is better than your way won't do it either.

The best thing to do is to sit down with them and write some code. Then throw in questions along the way. I.e.

• What would happen if ....?
• Could we do this a different way?

The idea being that they come up with the better way to do something and feel some personal involvement in it. As for C vs C++ why not use structs to start with for grouping parameters and then just say why not change it to a class? There isn't really any difference and it is the more normal way in C++