Version was code written onto a CD-R

Control was a person who got a full 60K Salary for monitoring a room with a bunch of file folders with different versions of the software. When you made a commit you burned a new CD and brought to Tim on the 5th Floor.

You can't make this stuff up.

They used VSS for version control and in team of around 30 people only two folks had check in access. So how do I check in my changes? When you are ready to check in your files, you fill in a 'blue sheet' (a blue paper with form printed on it) by hand. You are supposed to write name, location on your computer for that file, VSS location of the file and comment for each file which you want to check in (by hand on blue sheet). I used to take one day to implement a change request but would take as much as two weeks just to check in the damn files as those gate keepers were always busy. And god forbid if someone else checked in the file which you intended to check in. The gatekeeper will send you back to reconcile the changes and you will be again at the end of the queue. Trust me, I used to get 'blue sheet' nightmares!

When I asked them why they have this weird policy, I was told that it was to prevent people from checking in the code with breaking changes and enforce code review. Mind you, while I was there, gatekeeper didn't review my code even once. Reminds me of the monkeys and banana story.

"Hey Tony, are you working on blahblah.asp? Oh, no?, Great, let me just pull a copy, don't work on it until I say I'm done OK?"

I was fortunate enough at the time (circa 2002) shortly after my arrival to put svn into place. I gotta say though, once you now how to do something the completely wrong way, it's much easier to do it correctly. Ugh.

Before making each change, my team's 'architect' (almost hard to say without laughing/crying) copies her entire checkout folder to a backup folder she has created... painstakingly numbering each backup by date and time. Her explanation: this way she'll be able to revert anything that goes wrong.

So yeah, not real sure why we bother with ClearCase when we have team members implementing ad hoc, informally-specified, bug-ridden, slow implementations of half of Git.

Although the backups were pretty important because the founder was paranoid and insisted that we put the hard drives and swap space of every machine through 25 runs of shred at the end of each day.

The code was written in C++ but the CTO was a Fortran programmer! So no inheritance, no function overloads, no private data. And no malloc/new - there were several global buffers of different sizes statically allocated at startup and you used these, managing your own pointer offsets

The task was parsing datasets in a variety of formats (one per vendor, hundreds of vendors.)

The only acceptable way was substr. Everything else causes "memory fragmentation," apparently.

The language was Perl.

My next job was at Morgan Stanley, which had great infrastructure, both for Perl and otherwise.

I am leaving a company that uses a certain lightweight language to build web apps using CGI. There is no way to load libraries except by recompiling the runtime, and we do not have the C source code for that runtime in our possession. This means every library out there (even for the particular language we use, thanks to the fact that we're using a 9-year-old version of the language, and the inability to load binary libraries) is NIH'ed out from the start! Interfacing with external tools is broken because the function that runs system commands has been changed to be async with no access to the standard streams of the process it creates.

The product that is built on top of this is designed to let people build applications using flowcharts with a visual editor... but the "programming" that is the result of this system is essentially spaghetti code with GOTO, numbered labels, and a single global scope. Nodes in these flowcharts are labelled with 100, 110, 200, etc. by default and are laid out automatically, so there's no way to understand a routine at a glance. Variables in a flowchart get clobbered by other "subroutines" when they are called. Everything is indirections on indirections on indirections. I could go on... but you can get the idea by looking at this: http://imgur.com/ZKCU.png

This is all seen as advanced next-generation modeling that provides massive productivity gains over standard programming practices.

At one job I introduced SVN and Tortoise to try to bring version control to the project. A few weeks later we were using Visual Source Safe because the contractor goons couldn't grasp anything but VSS's Visual Studio integration. They also moved to doing development on one shared drive so that updating the whole tree could clobber someone's changes that weren't checked in.

I was also instructed to not use document.getElementById(), since the IE de-facto "standard" was to just refer to the element by its name (or whatever was going on back then).

Ha, I've run into this one as well. Blew my mind, they actually thought of this as smarter because it avoids any single point of failure in the code, like a battleship where there's a spare everything. Some people are just too stupid to be coding.

I was there on a project where the client's IT department had implemented a universal library for doubly-linked lists. None of my fellow programmers understood how it worked (clever use of macros to get pointer offsets) and management would only use it for that particular client.

(They charged hourly for the "customizations.")

Well, that's a good point. Fixing the database is great, but there has to be someone who understands the system after the intern leaves. At that point you need to figure out who would maintain after you leave and get them to be the champion of the new system.

1. Every Java exception that can possibly be thrown from a method must be caught, logged, appended to a new Java exception, and re-thrown. Fully 2/3rds of the code base was this sort of make-work.

2. They followed the traditional naïve model of distributing a system: break it into functional units, and put those on different machines. Win! Well, except that now every single query needs to talk to six machines, all of which need to be up.

3. Their system, running RMI, was of course implicitly multithreaded, because that's how RMI works. I didn't see in the codebase any real attention paid to this, so I asked about it and the project lead said "the two guys who know threading aren't in at the moment, but we'll schedule a meeting Tuesday when they make it in" on a team of thirty. Needless to say, the resulting system was a complete mess...

I do agree with your point that logging exceptions that might be handled upwards the call stack is silly and probably makes the whole log useless.

Also I'm not allowed to use OCaml in production systems because too few people at the company speak it. Annoying for me, but again far from ridiculous.

We do it that way so the business logic exists and is enforced in one place...Only the most trivial applications can afford to put all their business logic in the middle tier.

There are much better ways of enforcing business logic and controlling it all in one place, which would be compatible with configuration management/source control and much more convenient for most programming teams.

(Namely: just publish the business logic as a library and have standards that dictate its use. These can be enforced using automated scripts and a little process. You are also not restricted to the middle tier, though I'd still say it's a good idea.)

LOL!! Why not put the business processes in the standards too, then you won't need any code!

The point is, no-one running any apps against your database has a choice but to respect the business processes if it's all implemented in stored procs. You are protected from malice, from incompetence, from simple human error, and your auditors and regulators and shareholders are happy. Maybe no-one cares if it's only a website.

Also I am hilariously amused that you don't think stored procedures can live in version control like any other source code.

I'll note I'm not talking from experience here, I'm just speculating and hoping for somebody with more practical experience in the matter (or better insight) to enlighten me.

Most of the time, it's because the organization thinks in terms of SQL and relational tables. There are better ways to do business logic.

But of course, the middle layer that applications talk to need not be the database. A simple RPC server between the apps and the database makes maintaining the system significantly easier. Your procedures are "normal code" that you already have a toolchain in place for dealing with. (Testing, libraries, version control, etc.)

The environment is richer, which means the middle tier can handle caching, sharding, replication, auditing, and anything else that you might need to add. And, you can add these things incrementally, without touching the apps that speak to this server.

IMHO, stored procedures are a quick hack that are barely viable for even the simplest tasks. Many people seem to disagree, but I doubt they have ever considered any other way.

(A notable example of this system is Flickr. Their internal apps, like the public web interface, use the Flickr API to do their work. In this case, the web app that powers the API is the "middle layer"/"RPC server". I think this worked out pretty well for them, and it made it easy to expose their database to third parties.)

1) Sproc 2) Scattered around the app haphazardly

The only apps I've seen use the BLL-as-an-sproc trick were written by people without any experience writing scalable code at a real company.

Promote code that deletes the entire production Customer Database if the user hits "Esc" on Form 11 by accident: no problem. Unless it's indented 3 spaces instead of 2. Then it's rejected.

I understand that QA rejected it if the coding style stated that 2 spaces should be used for identation.

I reject your comment because you used two >> to denote a "quote" instead of a single >.

It didn't take long til everything started crashing from buffer overflows, so they just increased each MAX_SIZE definition to some ridiculously huge value. This made some of the top level data structures hundreds of megabytes. Developers complained that memset would take multiple seconds to run, and so they suggested just removing the memset calls to make the code "more efficient". Another developer suggested replacing all calls to "abs" with "if (n < 0) { n = -n }" because it would also be faster. I quit soon after that.

My main gripe is that while those two parts of the project were under source control, the database definition was not. So, while we could revert back to a previous version of the code, there was no way to revert back to the database schema that the code relied on. We were able to autogenerate database creation scripts (which we would use for deployments) but management would never let us check those script in under source control (which would have solved a lot of problems). The manager was a guy who liked to let wizards auto-generate code for him, and the idea of maintaining a sql-script that contained several thousand lines of code was just too much for his brain to handle.

No use of STL, using a hand-rolled dynamic array instead that grew by a constant size instead of doubling.

Extensive amounts of application logic written right in the GUI builder's generated event handlers, for the company's very large flagship product.

"Apps" Hungarian, on the other hand, is a wonderful system where the prefix describes the purpose of the variable (such as us for "usafe string" and ss for "safe string"). It also describes function naming convention (ss_from_us for "Safe string from unsafe string") so that you can easily tell if you're making a coding mistake. Compare:

  $ss_username = ss_from_us($us_username_field);

  $ss_username = $us_username_field;

Great article on Hungarian notation, why it used to be good, and how things went horribly awry. Takes a while to get to the point, but he's convincing.

sorry, couldn't resist

The same place barred the use of code generators, the use of snippet macros, and they barred admins from creating automated scripts/utilities to automate gruntwork. They likened it to taking a math test without a calculator -- you should be able to do it by hand if you can supposedly do the job.

The same place also required that comments were not to be made in source code files. They should only be made in source control check-in comments.

The same place felt refactoring was an unproductive activity unless it corrected a specific "bug". Scalability and performance issues weren't considered valid bugs - it was fast before, so why would it ever be slow now? Blame would be put on the hardware until network ops bit back. Then you would be lambasted for your application not scaling 4 orders of magnitude on the same hardware when that wasn't part of the original requirements.

One place I worked for did not allow developers to use the bug-tracking system. Instead, someone from QA would place printout of open bugs in a bin. You were required to take the bug from the bin, back to your desk, and when completed, fill in a form by hand detailing the explanation and attach the appropriate colored paper strips in the right order so it could be triaged appropriately.

The same place migrated customer data to their product by hand. Using Excel. We jokingly referred to this process as "electronic handcrafting". The reason was because it was faster and resulted in fewer reported defects after deployment. Someone in that department got fed up, so she had me create ETL processes for the four most common competitor products. Time-to-install went from 4 weeks to 4 days and the error rate dropped 98%. It won over the COO and some staff, but made me enemies with plenty of others.

At the same place a sales manager convinced the COO that RAID1 should be considered a viable backup and disaster recovery solution. We were tasked with making it so RAID controllers would not back up certain types of files.

Another place I worked for as a contractor insisted that their web app was written in ColdFusion. Despite not having any other contractors past or present, and the market not having any ColdFusion developers. The reason ended up being is it because it "sounded cool". Needless to say, they have an app still running on ColdFusion 4.

I've worked in too many places that are adamant that "backups" are all the database version control they need.

I've worked at a place that would expect me to develop APIs for certain products and systems we had, yet refused to allow for a requirements gathering phase. I was actually fired trying to explain that I can't build something when I don't know what I was building. Reason was so the new CIO could bring on a contracting firm run by a friend of his. Three other people have since quit in response.

Additionally, you'll hear enough horror stories if you talk to those who work in IT departments in regular companies that aren't doing anything interesting because no one's been able to present a solid business case as to why IT can add value or affect the bottom line. Though sometimes the works is simply gummed up by political battles and everyone's afraid to go to HR or to make an attempt to knock down those walls in fear of losing their job. What you read about on HN is what you'll see at the right-end of the bell curve, and often isn't representative of your average company.

Most of these issues were driven by politics. In a lot of situations (electronic hand-crafting, manual bug-tracking) I was able to drive change from within. Granted, they took months. However people were afraid of opposing the head of QA because A) she was a lifelong friend of the founder's life B) she was predisposed to think all developers were idiots C) they weren't equipped to traverse that delicate political minefield without at least losing a leg in the process.

The scalability/performance issue one? This was at a private sales-oriented company with a billion dollars in annual revenue. Again, mired in politics. Their entire e-commerce system was built by guys who were completely green at the time, and they hacked it together. He was best buds with the CIO, and was... a pretty passionate guy, and very defensive. The average person with a spouse and kids to support didn't feel it was worth risking their job to improve the architecture if they couldn't present a decent argument and it came across as hurting his feelings. Me? I spent far too many lunches talking with developers, guys in network ops and analysts to come up with ways to cache data and partition functionality so the thing could handle the existing load and scale in the future. It took buy-in from stubborn developers who normally pointed the fingers at the database or the servers, network ops guys who pointed fingers at the developers, and a testy data architect who had a serious row with the development manager.

I've learned a lot from those experiences, especially the social problems that can exist in team-based development, and how to present solutions where even the most stubborn-minded individual can "get it". I've also learned that these problems exist nearly everywhere, just more so in some environments than others, and when you can solve these problems and when it's instead best to learn and move on.

You had a biographer leading QA?

Sorry, couldn't resist.

I'd written some script in ruby to help us automate some maven grunt work and they said they'd rather spend 6 hours doing it manually than run ruby as they hadn't vetted ruby.

It had to be written in PHP. Why? Because we were moving to PHP.

So I wrote it in ColdFusion and used PHP REST webservice to get the data.

I still to this day do not understand why that system is now part ColdFusion, PHP, Flex, and Perl. :)

Great company though, excellent people to work with.

  $row[6] = $src?str_replace($src,($table[$src]?$table[$src]:$src),$row[6]):$row[6];

  seen them in tabular format ? you know they're great :
  have you seen them abused   ? you think you know     :
  have you thought about it   ? you think you know     :
  get the gist from this      ? good                   :
                                I can't help you       ;

  (cond
    ((seen-them in-tabular-format)  '(you know they are great))
    ...)

That said, that made complete sense.

: (or at least have you thought about it ? you'd understand why

: (or at least you can get the gist from this ? good

: I can't help you))

Sorry, not perfect but with some indentation would do the job quite nice.

Sometimes is not what you write, it is what you don't ;)

    <?="I","smarty pants"?"don'tget":"see";?>it.

Have you read the Drupal source ? Exactly : Take a look

Then the Chairman of the company, a fellow who supposedly had a law & math degree, told me that he would be doing the design with me (???). I sat down as he started writing buzzwords on the whiteboard. I jotted down a bunch of nonsensical words like "powersearch", "hypersearch", "megametasearch", and tried to write down what each meant.

Once the buzzwords were out of the way, it was onto the real meat and bones - the design!... except, in his own words, "At XYZ, we design the database FIRST and then design the program on top of that". Think about it. No objects, no user story, no nothing - just "DESIGN THE DATABASE". So I sat slackjawed as he started listing stuff like "Oh, we can use an enum for the airline companies... hmm, I wonder if int is too big for the id, maybe we should use smallint?". I tried to steer him towards the more fundamental questions of "What exactly do we want?", but he was having none of it.

I spent 4 months working on that software, and 2 more months wasted in other ridiculous projects he had before I tendered my resignation.

Although many of like to think that cold, hard logic is the only suitable method of reasoning with somebody, the reality is that even programmers are somewhat human. We're all proud, emotional souls.

If, like me, you've spent half a lifetime on your own, hacking and tinkering with computers, your skills in handling people may be somewhat underdeveloped. I've recognised this in myself and have been trying to do something about it. I can thoroughly recommend Dale Carnegie's classic book:

http://en.wikipedia.org/wiki/How_to_Win_Friends_and_Influenc...

In most cases, it should be possible to win over the stubborn manager or sensitive programmer who's blocking any progress towards sane development practices. There's plenty of material in the Carnegie book suggesting how one can gently persuade people, i.e. how to win arguments. In hindsight, a lot of the book's advice seems obvious and corresponds with my own experiences, but I needed somebody to make it all explicit.

I have first hand experience of having to placate a sensitive, confidence-lacking programmer. A few times it's been necessary to reject his ideas or code, and he's taken it very personally, being unable to separate in his mind an 'attack' on his work from an attack on him. Once you know how, it can be fairly easy to reassure him.

I've never had the problem of a stubborn manager who thinks he knows better, but I have a good idea of how I'd approach him and try and persuade him of the right way to do things. Then again, I still feel like my people skills are great only in theory, and somewhat lacking in practice.

    foo->vis = a || (b || !c && (...)) && z;

This resulted in my two or three line statements turning into many more lines, which then gave them cause for concern because their style had swelled functions to where they thought they were getting too large!

Plus, the C compiler, one of IBM's, produced better POWER code for my line than theirs.

I finally got them to back down when I gave them a code sample in their style for study. Even when I pointed out it had an error they couldn't find it. I'd deliberately missed an else-block off an if-statement that had started a dozen lines before. This would mean foo->vis sometimes wasn't written to at all; impossible with my version.

As for the very last point, maybe someone had some data to show that sub-domains increased response time. Alternatively, maybe subdirectories inadvertently introduced less code re-use at the company. Who knows. In business, sometimes there are stupid rules simply because someone thought it was cool. You either abide by it or bring forth some data to show why the rule is wrong (or could be better).

  template <typename T>
  class NotAPointer {
    T* m_pointer;
    T* set(T* p) { return m_pointer = p; }
    T* get() { return m_pointer; }
    NotAPointer(T* p) { set(p); }
  }

Microsoft (and many other large software companies) prohibits their programmers from viewing GPL'd source code. This policy is based on the shark-infested waters of our litigious society.

This is Microsoft's open source division: http://port25.technet.com/

They have to be kept away from the proprietary intellectual property. It's like separating your dairy and your meat when keeping Kosher. Microsoft has to separate tainted developers from untainted ones.

I hope you feel better knowing that you probably bank there ;)

I've rebuilt many a template when the code given to me is in bad shape.

* No STL ("too slow", and other reasons) -- had to roll our own giant, buggy core library

* No member variables ("compilation too slow") -- had to put everything in a predeclared struct, have a pointer to it, new+delete every ctor/dtor

* Wasn't allowed to use "configure" -- instead, we'd be forced to run ./configure, and commit the results into CVS; our 64-bit build didn't work so well

* Everything must be written in C++ -- even stuff that's usually written using simple shell scripts ("makes everything easier to understand")

* On Windows, we had to use Visual Studio 5.0 -- couldn't use any parts of C++ not supported by that compiler

* Everything was written in-house -- including 4 networking libraries. Three of them by the same person.

The list goes on. *Hits the bottle

Would you really ok a code review where every line (hell even one or two lines) took up 200+ chars?

Thank god I left after a year.

Going forward, when you interview, you should ask about development environment, version control, testing practices, etc. You should ask to talk with some of your future coworkers.

If an environment is toxic, riddled with politics, poor engineers and bad coding practices, it's admirable if you try to change things - but you probably won't succeed. You're better off leaving and finding a better place to work.

if(str = "hello")

See: http://stackoverflow.com/questions/655657/0-variable-or-null...