Or so they think. 

I remember shortly after we sold our company to Symantec in the 80s, one of the board members wanted a feature in our product, and the team didn't understand what he was asking for. I didn't either, but by then I had already been sidelined. Everyone on the board thought they did what I did. I didn't fight them because I was tired. And it was a constant struggle for me to get the features I wanted in the product from a devteam I built. And a codebase I wrote, but no longer managed. 

The lead developer, who happened to be my brother, asked me what he should do about the constant requests that came from the board. Ones that I agreed were far too vague to even begin to think about implementing. I said he should continue to respond to the board member honestly and truthfully. Tell him you didn't have enough information to do what he asked. Offer to help him explain it. Play twenty questions with him.  

He did this, with predictable results. The board member didn't like it. He thought the developer was being difficult. He thought he was being manipulated. Maybe he was, I wasn't there for the meeting. 

The board member, who had taken some Comp Sci classes as a college student, asked for the source code so he could implement the feature himself. He had a little spare time next weekend. My brother was offended, as he had every right to be. This is the point of this vignette. To the board member my brother and his team, who had shipped award-winning market-winning software, was just hired help. In his own mind he could do it better if he had the time and were given a chance. I suppose this is understandable too. If the result of one's work is something easy to use, therefore the work itself must be easy. But anyone who's ever done anything hard knows it's just the opposite. The easier something is to use the harder it is to implement. 

So the developer asked me, again, what he should do. 

I said give him the code.  

The way I figured it, either he pulled it off or he didn't. If he did, at least we'd know what he was asking for. Because when he sat down to implement it he'd have to answer the questions he didn't want to answer verbally. If he failed, maybe we could have the conversation we needed to have. Or maybe he would appreciate how hard the work was. Or whatever. 

There was a third possibility. We would never hear from him again. And that's what happened. I can only imagine what he concluded. When he looked at the code he must have been shocked to find something complex and intricate. Why isn't the source code as simple as the software? Hah. When you figure that out let me know. 

Now, I have to say that sometimes it's a good thing to give users source code, because very rarely you find a user who is so motivated to get a feature that he'll hack it in there, in an egregious fashion, but well enough so you get the idea. When no other method works, it's worth a try.  

But developing commercial quality code is not for sissies. It's hard. And the bosses, who think we're just hired help, are wrong.