Software Best Practices

I find it interesting that the 'construction' forum has the fewest posts. How can that be, when it is the one thing we are guaranteed to have in common? All sexy processes aside, there is no way to avoid constructing the code. Too often I have worked with groups that proselytize new methods and tools and yet ignore the tried and true approaches to constructing quality code. Don't get me wrong, I am a big fan of some of the new methods and would never go back. But at the end of the day, I have to produce code that works. Whether this code is requested in a 3 week iteration plan, or a horrid Gantt chart, my tools don't care. I have puzzled this over more than once, and all I can figure out is that constructing code in a highly disciplined way just isn't that sexy. There is no instant gratification. Is that the problem?

 It's certainly true that we seem to place little emphasis on the design of the actual code.  I suppose since our testing is typically focussed on the functionality, we may tolerate poorly structured code and since individual developers in my limited experience, are usually free to structure their code as they see fit, we tend to rely largely on unit testing and reviews to detect defects.

We've used buddying as a means of picking up on poorly structured code and to encourage refactoring, following design patterns where appropriates, etc, though it's early days really.

If I can parody what can happen (though of course in our ideal worlds it doesn't - I don't want to get it in the neck :)) :

We start with a nice clean design, well-structured, high cohesion, low coupling, clear interfaces, clear linear dependencies, etc.

Then we discover part way through development the need for another component, or it might just be an uncontrolled bright idea. Rather than rework the design (business pressure is typically blamed), we "extend" an interface that results in widespread rework amongst dependent components.  We try to fix the problem at the code level rather than at the design level because we fool ourselves into thinking it's easier, quicker and cheaper.

To respond to the changes in interfaces, we "move" some functionality into more convenient components thereby decreasing cohesion and increasing coupling, oh and in the process invalidate a whole swathe of tests which we haven't time to rewrite.

Once we have produced something that just works (no really, it only just works), we try to get together a set of tests that focus on the high risk areas, except that now we're not so sure which those are.

The resulting code which started clean can end up in a mess, very difficult to maintain.

Part of the reason this can happen is that we might have coding guidelines and standards, but they are sometimes thought of as low priority. I can agree with that on the level of things like naming conventions and layout (which are of lower importance) but I think we lose the focus on properly defined interfaces, clear design of classes, etc.

Coding style is quite a personal thing though so the trick is influencing the parts that matter most without restricting the creative scope of the developer.  We try to avoid arguments about coding style but pick up on design patterns, refactoring, scope and security, etc, using a buddy system. It's early days but we are starting to pick out some strategies.

One thing we struggle with is continuous integration. If we were more disciplined in the construction of software, no doubt we'd have less integration issues. I'm interested in the tried and true approaches to constructing quality code. What would be the top three?

I don't think that the problem has to do with how we work, rather with the character of the forums. Most of the discussions have started off with a decidedly theoretical twist. I could even say, too theoretical. Construction on the other hand is a very practical concern. The people that want to discuss construction may feel that this is not the proper forum for them. Most of the discussion in the forums until now have been about QA, either before, or after, construction.

During construction, it's not QA and methodologies, it's unit testing and JUnit or NUnit, the kind of tools I use for refactoring, the patterns I use in my design. If I want to enforce coding standards, I'll run FxCop (forgive my Microsoft-specific technologies. After all, that's what I do). I will also start my design by looking at the available software factories, at the Enteprise Libray pacakges and automated guidance. I will decide whether I will opt for the CMM or the Agile methodology for my Team System project. Or maybe, seeing how expensive Team System is I'll choose Subversion and CruiseControl.NET and try to follow the methodology steps (even the dreaded storekeeping progress reports) by hand. Do I use the .NET controls or do I buy a control suite?

Maybe I went into too much product specifid detail, but I want to make the point that getting too theoretical about construction isn't going to help the forum. It scares people away.

As for disciplined construction, I don't think it's just sexiness. During construction you come up with problems that were not addressed in the previous design phase, scheduling conflicts, you find out that the object guru the HR department hired isn't, you discover a better way to solve a problem or worse, you discover that the original solution is flawed. In fact, construction includes a lot of requirements refining, designing and testing. Putting too much discipline on it will not guarantee better code quality, just more work.

You mentioned something that I think is important to this problem.. "Part of the reason this can happen is that we might have coding guidelines and standards, but they are sometimes thought of as low priority." Many developers do see these things as either low priority or an intrusion on their creativity. I have long since abandoned the idea that coding style is a personal thing. If I had to pick some tried and true things:

-  pick a coding convention and enforce it, just do it, this makes the next item easier for everyone involved

-  frequent code reviews, the earlier the better

- static analysis of code, there are so many versions of lint for every language that I am familiar with, it is a crime not to use them. To find bugs before you have executed code is worth lots of time and energy. And the new tools that are coming out for static analysis are taking it up a notch (has anyone used the tools from Coverity?)

- it should go without saying, but I still work with people who don't consistently use a source code control system. This is such a recipe for disaster.

I have a personal story about these very things. I work with a client on a medical device and when I arrived, the software was being written by a hardware person. They had received Rational Rose training and were supposedly using UML. But in the meantime, they were not using scc, they did not have any coding conventions, were ignoring compiler complaints in their builds, using massive global variables in a C program, etc. While I love UML, I told them to stop all efforts with it, install a scc, establish coding conventions, purchase PC-Lint and start code reviews. Until some basics were in place, I knew that anything else was a distraction from what would really give them a huge payback. And this is a medical device! Scary.



 

As a contractor, I treat coding standards as a condition for acceptable work in the contract. That is, if my code doesn't conform to the standard then I will fix that free of change. Sometimes I have to force a team to develop a coding standard first. But once we have agreed on a standard I'm strict about sticking to it. (It would cost me otherwise.)

susan:

I find it interesting that the 'construction' forum has the fewest posts. How can that be, when it is the one thing we are guaranteed to have in common? All sexy processes aside, there is no way to avoid constructing the code. Too often I have worked with groups that proselytize new methods and tools and yet ignore the tried and true approaches to constructing quality code. Don't get me wrong, I am a big fan of some of the new methods and would never go back. But at the end of the day, I have to produce code that works. Whether this code is requested in a 3 week iteration plan, or a horrid Gantt chart, my tools don't care. I have puzzled this over more than once, and all I can figure out is that constructing code in a highly disciplined way just isn't that sexy. There is no instant gratification. Is that the problem?

Perhaps we are all too busy constructing code to post here? 

I think there are two reasons this forum hasn't attracted many posters.

1. The "construction" forum covers the same subject with the numerous development forums out there. The primary audience of this forum would be senior developers/architects and QA professionals that understand coding.
2. Posts attract posts and an empty forum gets no posts. You have to reach a critical mass of posts for a forum to take off. Readers tend to avoid forums with too few posts.