My Beefs

C / C++

Including Code in header files

We all know C/C++ typically has 2 files. Header files (.h) and source files (.cpp). Header files are used for 'interfaces and definitions' while the source files contains the implementation. For example.

myclass.h

class myclass
{
int dosomething();
}


myclass.cpp

int myclass::dosomething()
{
cout « "doing stuff" « endl;
return 0;
}


Now notice in the header file, we define the class and in the cpp file we provide the implementation. Now, some lazy programmer, seeing as to how myclass is very simple, they might just decide to skip the cpp file. The might define it as this.

myclass.h

class myclass
{
int dosomething()
{
cout « "doing stuff" « endl;
return 0;
}
}

So what's the problem here? It doesn't seem like that big a deal apart from my nitpicking on separation of interface and declaration.
Well try working between the two models during a project. Suppose 10 files will include "myclass.h". Now if I make a change to the implementation to dosomething(), all 10 files need to be recompiled in the model with only myclass.h. In the model with myclass.h and myclass.cpp, ONLY myclass.cpp needs to be recompiled. This save a heck of a lot of time. Trust me on this. On any project of a reasonable size, the number of includes grows to insane levels.

So what is the lesson. No matter how simple you think a class is, please make both a header and a source file. You never know when someone will want to change the implementation. Even if they don't need to change it, they might need to add some debug tracing…Just do the right thing here. Don't start about performance and inlining please :) Almost no one is actually writing software where inlining is going to make any practical difference. If you happen to work in such a high performance field and know inlining is the way to go, then more power to you :)

Metrics / Performance Measurement

Let me tell a tale of a company I worked for that tried to outsource some work. The work came back and it looked like they tried to maximize the number of lines. Code was literally copied over and over again instead of being put into a function. It was hell to work with.

We all came to the conclusion, the guys doing the outsourcing must have been paid per line of code or something, because it would be work to make the code so long.

Which brings me to measurement and metrics. A lot of companies are trying to make more use of 'metrics' to measure the performance of their employees / divisions. Metrics are great…if they are correct. Creating correct metrics is hard and requires constant thinking and adjustment. I would say it's better to have 0 metrics than to have bad metrics. Why? People tend to take action based on metrics. More often that not, have a bad metric and actually create bad behavior that would not have other be done.

Consider the initial example. If the outsourcing had been done on a flat fee (not lines of code), then the programmers would have had no incentive to make the code extra big, and they would have actually written better code. by introducing a bad metric, you actually end with a worse product (quality, performance, maintenance…).

Want a few more examples of bad metrics that I've personally seen?
bugs fixed:
This one was at a very large telecom company (probably the top one), and they had this policy of rewarding people who fixed bugs. The metric was 1.5 bugs / week. What this resulted in? People choosing easy bug fixes and more often, not taking the time to make real structural changes that are needed. It also resulted in frustration with the wrong people getting credit/rewards, which resulted in bad moral. Even worse, the wrong people got promoted which put them in highly technical positions and they made bad decisions…Oh its a vicious cycle alright.

Poor Managers

So of course this must frustrate managers. I mean how do you measure the performance of these engineers? how do you tell the engineer that is worth 50k from the one worth 300k. You know you probably can't. I can't think of a metric that would work. This is not an assembly plant where you can easily measure a worker's output.

I can think of a few informal measurement. Who do most engineers turn to for help? This will give you the key people. Interviews with some of these key people (who might very well be arrogant basturds :P ) can also give some insights. Maybe some peer reviews and just keeping in touch with employees through regular meetings.

Basically, just remember: no metrics are better than bad metrics.

Specialization

I've been a software engineer for a few years and I'm pretty good if I don't mind myself saying :) One aspect I've never liked is the complete separation between software and the rest of the business.

I used to work for a company that made equipment for mining/industry. It didn't pay too well; hence I left there. Yet, one aspect I loved about that company was that I was involved in everything. Sure, I'd code and play with circuit boards… But I'd also be answering questions on the phone, planning the next products, going to customer locations. In most of the companies since then, these are all separate jobs.
If I want to deal with customers, I become a field engineer.
If I want to do more planning, I become a product management professional.

Some places are more flexible than others. I'm always one that has the philosophy of 'it never hurts to ask'. Yet, good software engineers are very hard to find these days, so no matter how I try and branch out, the software part keeps dragging me back in. I'm still young enough that I like the problem solving involved in software. I think it's a chicken and the egg problem. There's some very good senior guys who probably leave development seeking management or project management or just bored out of their minds in software… imagine if you could keep these good guys in development. You'll probably end up with better products in any case as they would be done by experts and by people who actually understand customer needs.

The reality is no engineer spends their whole day actually coding. We just don't. If we are, chances are it means we've screwed up. So wouldn't it be beneficial to all to have your engineers be in contact with people and planning? Then go back and do the work as needed. How much this is done is a personal preference of course. I know some people with no social skills who probably don't mind just having a spec handed to them and being told 'get it down.' There is perhaps a need for a few of these people. Sometimes the technical requirements are so high, that few people possess that kind of specialization with a personal friendly attitude. Yet, is this the majority of jobs? Heck no.

Again, by allowing the growth of the individual beyond just 'coding', you make the job of staying in actual engineering work more tolerable. So more senior people will stay. Suffice to say, a good engineer with loads of experience is invaluable. You might even find yourself saving money. If your top engineer is also a program manager…away you go; you've just saved yourself a position.

Put it this way. Imagine if the field of medicine was treated as engineering.
You have the highly skilled surgeon who sits there at the operating table all day. They never consult patients or talk to them . That is handled by a friendlier person. They gather the requirements, then just hand the patient details over to the surgeon. You arrive, the surgeon does the job. To coordinate everything, the surgeon and other staff are managed by a business manager who overseas the operation and all aspects. Followups are done with the patient facing person. The surgeon awaits the next 'customer'. Needless to say, you wouldn't get many surgeons.

Telecom Standards

I write protocols. It's one of those things I do at work. For those of you who have never done it, read up on an RFC sometime (RFC2869) is the one I am reading now. Just type it into google and you will find it. There are thousands of RFCs…all detailed to describe some protocol.

Most protocols are decent. IP, TCP, UDP are all okay.
Once in a while though, you get protocols that you just want to strangle the people that wrote them. For some reason, telecom protocols tend to be especially frustrating. Not because they're hard or complex, but because it seems they go out of their way to make it needlessly annoying.

Right now I am working on Wimax… Anyone who knows about protocols knows about TLVs (tag, length, value) structure. Basically the tag=what kind of data it is, length=length of data, and value=what the data is. Makes sense as a very flexible protocol. I mean let's say I wanted to send information about you as a person.

This is version 1 of the protocol
tag: name length: 3 value: bob
tag: age length: 2 value: 22

For version 2, I add
tag: sex length: 1 value: M

You can easily extend information without ruining encoder/decoders or rejecting packets.

But here's the Wimax spec and it is TLVs inside TLV inside specialized structures with extra crazy formatting and the whole works. I've noticed other specs to this as well. You'd think the guys writing these specs would first design a flexible TLV type and then leave it as that.

I know how some of these things come about. Rarely is the standard written first. Companies start playing with technology…getting prototypes. They all get their products going at the same time as standardization is just beginning and then they realize theirs is not compatible with the others in the industry. So the standard must now navigate all the vendors and accommodate their little quirks in the most inclusive way so no loses out and has to rewrite their version.

But dammit…at least get the basic structures down. It's not hard to keep TLVs simple :)
And if you haven't dealt with RFCs in telecom, maybe you think I'm whining about nothing…maybe I am,

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License