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.
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".
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.
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.
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.
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);
}
}
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!"
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.
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.
Not that it's necessarily nicer, but generally I'd say duplicating functionality of the standard libraries or frameworks should be avoided if possible.
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):
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.
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.
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.
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.
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.
See also http://retrospectivewiki.org/index.php?title=The_Prime_Direc...