

Culture Shock: Programming for the Enterprise - reikonomusha
http://symbo1ics.com/blog/?p=2119

======
reikonomusha
Two parts of this post really hit home with my experience as well: the bit on
the "career programmer" and the bit on open source software.

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.

------
aram
Very good points; I'll be writing my Master thesis on the topic of Corporate
Social Responsibility / Human Resources and Open Source involvement for IT
companies, and these are exactly the things I want to target.

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.

------
reikonomusha
mirror cache:
[https://dl.dropboxusercontent.com/u/734346/html/programming-...](https://dl.dropboxusercontent.com/u/734346/html/programming-
for-the-enterprise.html)

~~~
Domenic_S
Thanks. Site was down for me.

------
zeckalpha
Are you still at Microsoft?

