Culture Shock: Programming for the Enterprise
symbo1ics.com
symbo1ics.com
When I worked in enterprise software, I got to be on a smaller team and we had a lot of slack in the decisions we could make for the software we were building.
I was absolutely excited about this project. There were so many facets of programming that could get touched. There were so many areas of software that we could learn about, like databases, efficient real-time image processing, operating systems, updating mechanisms, etc. Best of all, we were fortunate that bureaucracy was minimized. People within two degrees of bureaucratic separation usually kept their noses out of it, and it worked out well.
The trouble was: both of my project team mates were Career Programmers™, in the worst possible way. We were using a programming language that allowed a variety of paradigms. Often, the functional paradigm was both idiomatic and clearer. However, both of my team mates had never touched FP. They were previously C programmers. So they thought it would be best to code in this language as if it was C.
This was horrible. I tried to politely suggest different avenues of programming and a few tools they could learn from, but that's "not part of the job." There was no interest in learning something beyond what they knew because it wasn't part of the job description.
That's bad, but it's even worse that they actively didn't improve their style of coding. They hadn't used object oriented programming either it seems. Or structs before. So what did they do when they wanted to pass around state? They made global variables.
Most of the GUI code was a sloppy mishmash of global variables to communicate between different components. It was awful. But it worked for them in the past, surely it'll continue working.
When we ran into bugs as a result of it, they didn't think twice that the style of programming could be the source of the issues. Instead, they viewed it as an error in the way their "local logic", and just slapped a bandage over it assuming that'd fix everything in the future.
In all, they just came to work everyday because it was a job. There was no excitement about what they have been doing outside of work, there was no passion for the subject one of them got a masters degree in.
Open source was another huge issue, albeit mostly moral. We essentially stole open source code left and right in order to accelerate the development of our business. I wanted to add a note somewhere in our project describing the open source projects we used, and even more, open source some completely decoupled infrastructure to our main product.
But in the bureaucratic hierarchy, up about 3 levels, there was fear of it. We actually had to sneak in open source software, because if we brought it up in a meeting, their response would be negative. Open source software was supposedly low quality, and if it was worth anything, they'd be charging for it.
When we did convince them to let us use an open source library, we weren't allowed to send patches upstream. "We aren't working for free." This was absolutely mind boggling. They gave us software for free, the least we can do is send improvements.
Lastly, and I think the article puts it best:
> I think this stems from the fear that by admitting you didn’t do all of the work, you will somehow devalue your product.
This was absolutely true. If shareholders or board members see a message in our product saying "we happily used X, Y, and Z", management implies we would be seen as inferior, because we (supposedly) needed crutches to program. This very often led to reinventing libraries. The worst was when we greenspunned an entire database system.
The kind of behavior these people demonstrated, a merciless scavenge for software to accelerate the business, a desire to pilfer and not share, really make things like GPL3 look charming.
Through working at a few of these kinds of places, I now try to figure out during an interview if the companies are of this type. When I asked pointed questions about these things, I've actually been rejected because I was not "enterprise enough". On the flip side, I've rejected offers precisely because I knew my work would be dominated by enterprise styles and systems, and more likely than not, I'd have coworkers who revel in—no, tolerate—that environment. So far, it has worked out well.
It took me a good amount of time to explain my supervisor who is teaching management courses what is Open Source and how things work there. Even after that, I still think it's not quite clear for her.
The things that managers/purely business people don't get along with the most are the free and collaboration parts, because they are a bit "out of the box" for usual business mindset.
Good read.