Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Software as a profession sucks, a rant.



Basically I have been a computer programmer professionally since the
early 1970s, first at a bank, then at a couple of fast food chains,
Raytheon, a few startups, and as a contractor with many years at
Digital/Compaq/HP.  Different companies, whether they are in the
computer industry or not take some widely different views on how they
manage. But every company must make money to survive. Larger companies
can lose money for longer peiods of time, but economics aside, how these
companies treat software professionals varies widely. In the bank, we
worked on a work order basis. Our bank or some of our client banks would
ask for changes, and that would filter to us. We also had firecalls
where the software would fail, and we'd have to fix it. Imagine a
midnight call from a Cuban computer operator who could barely speak
English waking you up out of a deep sleep at 3AM.
Basically, in a non-computer company essentially the people in IT are
simply at the same level as the accounting staff, or other areas of the
company. I found in some technology companies software was only what
made the hardware go. In other companies, like Digital, the software
engineers commanded more respect because of the nature of the product.
But I have also worked with other companies that have software products.
(I've also been a manager in some cases, but the main reason I became a
contractor was because I didn't like to be a manager). Essentially, in a
company that has software products, many times a product (or release)
may be announced with certain features. Sometimes some features my be
required under contract as well as release dates. There are 3 variables
in software development, time, resources, and function. Many times, time
may not be a variable, and function may also not be a variable, so you
need to add more resources. I was involved in Digital's Unix, and while
our release schedules were somewhat flexible, many times we would have a
major contractual obligation for specific functionality. We also had an
obligation to pass a number of standards test suites, such as X/Open and
SVID. So, to meet the contractual obligations, sometimes some planned
functionality would be deferred to the next release, including some
important bug fixes.

The bottom line is that we are not going back to the 90s when many of us
software guys made some good money. After my contract with Compaq/HP
when HP bought Compaq, I was at the end of my 3 years you have to leave
for 90 days, and when I cam back a couple of years later to the same
desk and computer, I was making a significantly lower hourly rate. I
just got my first increase since then last month (which is amazing in
this economy except I work for a company that develops Risk management
software).

It really is not so much how a company treats it's engineers (software
or otherwise) it is how a company treats its employees.  We once had a
VP of IT tell us that we had to be at our desks at 9Am and could not
leave until 5PM, and that lunches must be between 12 and 1. All my
colleagues were pissed because we routinely would come in on firecalls.
Some of us came in early in the morning, and others worked later at
night. It all came down to other manages would see us in the elevators
at odd times and would complain to our manager.







BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org