What technologies or techniques senior developers of today should *unlearn*

Question

Many questions here about learning new things. But what about unlearning?

When we used to develop software 10 or 20 years ago very differently, we counted RAM in bytes, libraries were very rare, IDE was an unknown word and Merise was king.

What should we unlearn today? What bad habits we should get rid of?

EDIT: unlearn doesn't mean forget. Rather to use old techniques that was useful in the past, use the new technologies (such as GC for memory management). But your past knowledge will always be useful today.

Answer 1

Everything

Following the vain of the previous answer, I believe all habits are bad and boxing. Falling into any sort of habit can be construed as a lack of creativity which will stifle your perception of new technology or options.

Learn patterns, don't make them a habit. Identify ones that work well and then apply them to new requirements. Don't put yourself in the mindset that every application must use MySQL, PHP with Zend, Apache 1.3, and Cent 5.4. What about CakePHP? CodeIgniter? How about using a different storage engine? Different language even.

The beautiful thing is most of the technology or paradigms in use are interchangeable. I can use ROR with MongoDB and Ubuntu for a basic CMS. I can set this up on an EC2 instance or an Ubuntu dedicated machine. I can serve content with a CDN and write backing scripts in Python. Add Redis for in memory session management with a ant script to deploy. These modular components allow you to have a diverse skill set that is necessary to be ahead of the curve.

Answer 2

None - Now I know this is going to be a controversial statement, but old technologies and techniques should not be unlearned because you never know when someone might find some old code that you have to dust off and understand and if you don't remember the technologies and techniques that were in place, that code is going to be a mystery.

Likewise, getting rid of bad habits should not be associated with unlearning and old way of doing things. In a lot of cases, I would argue that the old way of doing things might not be relevant, but they were generally done that way because they worked. Remember why it worked and use it to provide suggestions that might be useful to new technologies and techniques - just be sure to try and not force the old way of doing things on new technologies.

Update - With an update to to the question, and update to my answer. In terms of unlearning old technologies and techniques, I think that my original none assessment still applies as in a lot of cases, the old solutions work just as good as the ones based upon new technology and techniques. At the end of the day I think that it all comes down to the right tool for the right job. The age of that tool shouldn't make any difference.

Answer 3

Single-Threading. Get used to the fact that your program is no longer a "main" function that calls other functions; more likely, your code will be compiled to some classes that live in some framework, which might create some objects, and call some methods, in parallel threads whenever you expect it least. A global static variable is no longer just "ugly" and "hard to maintain", but rather, it probably makes the program crash because of race conditions.

Answer 4

Declaring all variables at the top of files

This may have been good practice in the days of primitive compilers, but is not required in modern programming environments. Nevertheless, a lot of programmers who have been around for a while seem to do this without thinking.

My preference is to see variables declared as close as possible to their first use.

Answer 5

How to overengineer everything for future-proofness. I get the impression that heavy OO engineering for every conceivable change was the paradigm of the late '90s. Nowadays we realize that you can't plan for every conceviable change and every bit of futureproofing against changes you anticipate makes changes you don't anticipate that much harder. It only makes sense to future-proof your code against a few specific changes that are especially likely to actually happen.

Answer 6

Design by Database

If you're producing a business application of significant complexity, and the first thing that you do is produce a big chunky database schema -- instead of focusing on business logic, domain design, or service level interactions -- then please take that finished schema, wad it up, and eat it. Because that is about as much worth as you will be able to extract from that document, once you realize that an application logic should not be dictated by database structure. In fact, the database structure, should only be dictated by application logic, and only when you have a clear idea of the domain (the problems your application needs to solve, and how to solve them). I would go so far to say, that I would rather see a working mock of the user interface before I see a database schema, or at least a UML diagram of the major components and classes.

Disclaimer: Of course this is a generalization that does not apply for ALL applications.

Answer 7

Unlearn the concept that well-written code is also well-commented.

I don't have a problem with any technology or technique in use today enough to say that we should all unlearn it. But this habit of writing comments to document and explain our code is so deeply (and unjustifiably) embedded in our profession. My annual performance review questionnaire has a question: "Writes well-commented code" - "strongly agree", "agree", "neutral", etc. I have convinced my manager that the correct answer to this question is "N/A", but how many others have come to the same agreement?

I just opened a random file in one of the two IDEs that were open on my screen at the time of reading this question and it took me a less than a minute to find this:

        /// <summary>
    /// This method creates a foo depending on the bar name.
    /// </summary>
    public static Foo GetFoo( string barName ) {
                ...
    }

Let's unlearn this.

Some reply is in order after 9 votes, 6 comments, and 18 votes seconding those comments.

I am protesting against the comment-favouring bias that we programmers have. I'm very concerned where, in the words of Robert Harvey, "erring on the side of more comments" may lead us.

Let's start with Greg.

1. Why did Greg's employer hire non-programmers to do a programming job?
2. If the job was to write a program in Perl, why give it to people "with only passing familiarity with Pascal?"
3. If the intent was to hire people with a skill gap and train them (by taking Perl classes, lunch-and-learns, pairing with experienced Perl developers, frequent code reviews, etc.) so that they didn't have to write unconventional Perl code and write comment explaining the intent to senior Perl developers -- none of this training apparently took place. Why?
4. And I am not making Greg's company solely responsible for the training; if these people signed up for the job, they made a commitment to learning a new skill, programming in Perl. Were they actually expected to act that way? If not, why? Did they understand that? If not, why?

You can see many problems in Greg's company right away, but Greg didn't say he'd kill to solve any of them. Before saying that, before probing root causes, we, programmers, are much more inclined to say, "if only this code had more/better comments..."

To Adam and @bigtang: I love good comments, too. The problem is, the vast majority of comments aren't good. There is lots of waste for every non-trivial piece of code with a good comment explaining the non-triviality. Adam, what if your business analyst needs to state those "unstated assumptions" and discuss them with a customer? Have your QA people talked to you about them? If you write a code comment about it and check it in and you are the only one of the four people (developer, QA, BA, customer) who has access to the source code, the chance is almost 100% the conversations will never happen.

We tend to see comments as assets, harmless in the worst case, and never as liabilities. Let's take a look at this thread. The original poster: "They're bulky and I'm always forgetting to update them. Do you [still] recommend using them?" The original poster is clearly concerned that they are a liability. But this opinion - "Use them as much as possible", it's so cool that they show up in IntelliSense - is a runaway favourite (60 upvotes).

Answer 8

Hungarian Notation

There's nothing wrong with "m_" for member variables but "m_sztrfgpCompanyName" outside of C or arguably in C programming it's overkill. That's what IDE's and modern compilers are for. (And yes, I know of all the dangers of void*, see "arguably")

Answer 9

I would like many engineers to break themselves of the habit of using XML for anything and everything. Perhaps it is just the clients for whom I have worked recently, but I consistently see poor old XML bent, twisted and perverted towards uses that do not suit it.

Specifically, I detest the notion that making a system configurable means loading and interpreting vast quantities of data from XML files at start-up. Rather than achieving the intended affect of adding flexibility and adaptability to a system, it tends to shift too much complexity there and make configuring the system an exercise in spell-casting and black magic.

Answer 10

Programming isn't always about how quick you can get an application out of the door

I often hear people claim the old chestnut of how much quicker apps were developed and released to customers 10-15 years ago, but unfortunately these people don't appreciate the kind of obligations we as programmers are now under, an app that was banged out of the door quickly was most likely fraught with bugs, security holes, lack of scalability and extremely difficult to maintain by anyone other than the person who wrote it.

It would be great if we could just switch off to the potential 10's or 100's of people who might try and hack our product or not bother to protect all of the personal information in it, or not give 2 hoots whether our colleagues would be able to maintain and extend it, but unfortunately the world doesn't operate this way anymore.

I would like the see the seniors appreciate how much more effort and thought is required these days in order to construct applications and websites.

Answer 11

C++ as a better C

It used to be that C++ was mostly a better C, but the language has evolved much past that. Fortunately, the people I'm working with also have, but not everybody has. The correct way to write programs in C++ is much different from in C.

Answer 12

A few years ago I remember someone claiming that developers could now forget all about optimizations like common subexpression elimination in loops, because "compilers are so much better now". It seemed reasonable at the time, but in todays world of interpreters and DSLs, a lot of those techniques are life- (or at least job-)savers.

I'm not really ready to give up on any of my "archaic" knowledge. It lets me take advantage of those old wheels that get re-invented every five years or so.

Answer 13

Unlearn your Bias

I can't tell you how many times personal bias gets in the way of the correct solution. Sometimes, inadvertently, I am biased and make sub-optimal recommendations. Sometimes others are biased towards the existing paradigm no progress can be made.

All that said, you need to also know when to stand your ground on your approach (of course in a cool, collected way).

Answer 14

Coding standards designed to format printed code

Apparently, some of us used to print our code. You know, to paper. Really. I have no regrets about being "born too late" for this one. So if your coding standards (personal or corporate) require formatting lines to fit on a printed page, please just think of the trees.

Answer 15

Cobol

I had suffered from people using Cobol mentality in other paradigms. I had to write it once in my life somewhere and this question helped a lot. I am talking about writing Cobol in other environments. In the country of origin there was a word for it: "Cololeiros" which initially I thought was a form of dance...

There is a nice story in "Code Complete" about the same in Fortran.

Answer 16

I have a couple...

Unlearn Database first design. As mentioned above.

Unlearn BDUF - big design up front.

Unlearn functional & design specs. Functional specs should go away. They're always outdated by the time something is relaesed and what is produced is almost ALWAYS wrong.

Unlearn well-written code is well-commented. This is wrong, as many are finding out. Comments don't mean anything if they're not well written, and often they're not useful anyway. Especially with a changing code base. If anything write tests, do TDD, and forget the in code comments.

Unlearn XML for everything. It just adds too much overhead to most things. XML is great for certain things, but as JSON and other technologies have proven, it isn't for everything.

Answer 17

Inventing the wheel

Back in the day, there were no easily reusable objects or online services we could just plug into, so we had to write our own before we could start tackling the real problem at hand.

It's hard always remembering to check whether someone else has solved a problem before setting out to do so, epecially when some part of your brain actually enjoys it.

Answer 18

You don't need to custom build everything.
Look to see if there's an off the shelf product that will do the same thing. (example, we build a time management system a few years ago when we could have just bought one. Would have been cheaper in the long run.

Your time can be used to code other things.

Answer 19

The expected rate at which technology changes.