People in your organization that grow legacy code

http://zeroturnaround.com/rebellabs/the-5-people-in-your-organization-that-grow-legacy-code/

by radcortez • 12 years ago

55 34 12 years ago

zeroturnaround.com

VLM2• 12 years ago

Isn't it really just one person, the manager who permits it?

relet• 12 years ago

You must be a manager.

VLM2• 12 years ago

LOL I've seen them work (or not) for a couple decades, and I'm observant. Boss has no idea whats going on = best polish up the resume, everyone will be needing a job soon.

brixon• 12 years ago

Yes, but some of those people are easier to spot than others.

We have all those people where I work and I have learned to know what questions to ask each of them to make sure they did the right things.

Quality cross group code reviews help identify this stuff fairly fast.

barrkel• 12 years ago

The best managers I've had aren't the kind of controlling, micromanaging people who could reasonably prevent it.

Informal design sketch review, peer code review, pair programming to mentor and induct. All processes that could be mandated by the manager, but work better from peers than down from on high.

mseebach2• 12 years ago

The corollary of that statement is that whenever a team does something good, the manager gets the credit.

himangshuj• 12 years ago

with regards to The Overly Energetic Engineer ,there is also the management which does not allow you to give back to community. Sometimes well known libraries have issues which are fixed inhouse but you cant contribute them back to community and you are stuck between devil and deep blue sea.

finalight• 12 years ago

omg i'm the smartass, i'll admit that

zwily• 12 years ago

I can think of examples of myself being each one of those at different times...

peterwwillis• 12 years ago

I was definitely the smartass when I started out. Every time I hear someone say the words "that's easy" or "couple of hours", I look back on my career and cringe.

brlewis• 12 years ago

Judging code is important, but this article seems to be judging people too much.

When I see unwieldy legacy code at Fitbit, I assume it was written by an overworked early employee wearing five different software-engineer hats, two of which they were experienced in. I assume they were working as fast as they could to get their startup to take off before the end of the runway, and that they anticipated having enough money to hire a team of people to clean things up later if they succeeded.

They did succeed, and I'm part of the cleanup crew.

Kiro• 12 years ago

Ok, I'm an idiot but how would you rewrite getDayOfWeek?

dsego• 12 years ago

I don't get it either.

ygra2• 12 years ago

    calendar.getDisplayName(Calendar.DAY_OF_WEEK, Calendar.LONG, Locale.US)

I guess.

Not that it's necessarily nicer, but generally I'd say duplicating functionality of the standard libraries or frameworks should be avoided if possible.

msluyter• 12 years ago

Well, this gets you the day of the week for whatever the current time is. The example in the article didn't do that exactly. It took a string of some sort (in what format, exactly, isn't clear to me) and mapped it to another string.

Assuming that the input string is a formatted date of some sort, then I think this would work, using JodaTime (minus exception handling):

    public String getDayOfWeek(String s) {
        DateTimeFormatter formatter = DateTimeFormat.forPattern("dd/MM/yyyy");
        DateTime dt = formatter.parseDateTime(s);
        return dt.dayOfWeek().getAsText();
    }

Xophmeister• 12 years ago

I think the joke is the `getDOWNum` call: `getDayOfWeek` takes a string as its argument, so presumably this is already something like "Monday", thus rendering the function redundant (i.e., equivalent to the identity). However, there's no implication of this anywhere in the code; the input string could be "2014-02-24", for example.

Maybe that's a bit of a long shot. Perhaps there's some standard library function -- I don't know Java, but the author seems to assume the reader does throughout the article -- to turn dates/whatever into day number. Maybe his joke is therefore, "OMFG! What a noob!"

In short: I don't get it, either...

MAGZine• 12 years ago

That could be it. My first glance lead me to think it could all be replaced with an enum rather than 7 switch statements (or, better yet, a library function).

"data" is ambiguous, too. I think that perhaps there are a few errors to demonstrate his point.

mseebach2• 12 years ago

1: Should have used a library function

2: not 0-indexed (there can be good reasons for this, but the context of the function should at least suggest the reason)

3: Doesn't handle errors - should throw IllegalArgumentException, and if should do it in the default handler of the switch. If you suddenly see "???" in the UI, it's not easy to track down to this.

4: If for some valid reason this can't be a library function, it should be an enum, and it should be used throughout the code.

    enum DayOfWeek {
       MONDAY(1, "Monday"), TUESDAY(2, "Tuesday") ...

       public int id;
       public String displayName;  // these should be private and have getters according to most style-guides.

       public DayOfWeek(int id, String displayName) {
           this.id = id;
           this.displayName = displayName;
       }

       public static DayOfWeek fromId(int id) {
           for (DayOfWeek d : values()) {
               if (d.id == id) return d;
           }
           throw new IllegalArgumentException("Illegal DayOfWeek id passed: " + id);
       }
    }

ygra2• 12 years ago

FWIW, the default Java API to get weekday strings is also 1-based (DateFormatSymbols.getWeekdays(); and Calendar.SUNDAY is 1).

a3voices• 12 years ago

In iOS, days aren't 0 indexed either by default. Sunday starts at one.

awda• 12 years ago

Ok, problem number one: Without looking at the code, what day is number 3?

jrabone• 12 years ago

  String[] names = { "UNUSED", "Monday", "Tuesday", ... }
  try { 
    return names[i];
  } catch(ArrayIndexOutOfBoundsException uhoh) {
    return "???";
  }

It's so easy...

Look, at least it's not a pile of @Inject DayOfWeekLookupAdapter dayOfWeekLookupAdapter with attendant 100kB Spring XML config, of which the unit tests will have their very own special cut and pasted copy. No, I'm not bitter at all.

bluesnowmonkey• 12 years ago

Legacy code... that's the stuff that solved business problems well enough to provide you with a job fixing it, right?

scj• 12 years ago

While I understand the reasoning behind the Elusive Firefighter, I think the example is rubbish. Set the license limit to MAX_INT. Surely two billion licences should be enough, and the problem is solved (with a high degree of confidence) within minutes. I don't know the codebase, but disabling checks may also suffice.

Depending on the company, refactoring legacy code is like walking through a minefield to get to a territory that isn't really desired by the higher ups. High cost, low reward.

As for the rule "If you see something wrong fix it properly!" I disagree in some cases. If you are a legacy maintainer, usually something is broken and management/clients want it up ASAP. The proper fix is rarely the fastest. Beyond that, you have to be careful when advising refactoring. If you advise it too much, in cases that don't really need it, management may not take your advice as seriously when there really is a problem.

fridek• 12 years ago

Surely four billion IPs should be enough. Oh, wait...

fournm• 12 years ago

I think we can safely assume that two to four billion unique users for a single deployment of some software that originally had a small user count and only four billion unique public network identifications are at a completely different level of risk for happening.

neverminder• 12 years ago

I don't agree that "the smartass" is the worst of 5. I'd propose a 6th one: legacy technology proponent. How many times there was a moment of decision what stack to use for a new project and there was always this one guy going "How about we use LAMP with XYZ PHP framework? There are a lot of 'coders' around we can hire for that and they will be cheaper than ruby/python/scala/etc guys".

misterjangles• 12 years ago

Or #7 the programmer who is too cool to use modern, stable, popular tools that would be perfectly adequate for solving the problem. Instead insists that the team write everything in unproven fad technology XYZ - then disappears when he/she gets bored in 3 months, leaving others to maintain a code base written on a abandoned platform.

apaprocki• 12 years ago

Having read the article, I'm pretty sure that person is #2 :)

adamors• 12 years ago

30 minutes in and there's already an ignorant comment about PHP. HN never fails to disappoint.

orkj• 12 years ago

I've been all of these, probably a couple of them only today...

DrJokepu• 12 years ago

I'm basically all of these five people. Except maybe for the intern.

People in your organization that grow legacy code

Related Stories