The Ivy Tutorial Strikes Back

We're continuing on with the Jim Moores Guest Post series, as Ivy proceeds to destroy his source code directory.

After my previous problem with the build.xml file supplied in the Ivy tutorial I hit another issue that I thought I'd share. The default ant build file given in the Ivy tutorial generates an example source file within the ant file and then builds it. I, and I presume many others, based their new ivy-aware projects on that file. It has the default targets for downloading and installing ivy. Yeah. Problem is that one of the targets looks like this:

Can you see where this is going? Note where it says to delete the entire source directory. Yeah. That just happened to me.

I lost about half a week's work. It was my own fault. Because I'm a Perforce refugee and we've decided to try using git, I was more hesitant than usual about checking non-working code into my own code branch just because i wasn't so familiar with the git style of doing things. So while I was trying to get the ivy problems ironed out I ran ant clean which promptly deleted all my source code. All of it. Well, except the unit tests.

Please, let this be a lesson that I've learned so that you don't have to. While I accept that this was my fault, I can't help thinking that as a rule no build file should ever delete the entire contents from the src directory, particularly not one shipped as part of a tutorial that one would attempt on existing code.

Ant, Ivy 2.0.0, and java.net.UnknownHostException

This is a Very Special Guest Post by Jim Moores, another one of the OpenGamma team. We thought this would be useful to the interwebs, and until we have the OpenGamma blog ready to go, we're all ranting as one.

Ivy is a great way of avoiding shipping all the dependent libraries with your code and making upgrading dependencies smoother and easier, but it can still be a bit rough around the edges. For those of you new to Ivy, it's a dependency manager that is built on top of Ant that goes off and downloads and installs all your dependent libraries given a pretty simple list in an xml file. It hit version 2.0 a few months back and started to be really useful with more and more projects switching over to it. Of course Maven has done many of the same things for much longer, but Ivy doesn't require the whole head-warping change of viewpoint that Maven does. To be fair to Maven, I've only used it in passing when building the MyFaces JSF source code and while I did get it working, and was impressed, it took a bit of fiddling. My general understanding of Maven is that it's more declarative than 'normal' build systems - you tell it what you need and you have to rely on it figuring the whole thing out and it requires you let go of the idea of targets and explicit flow control (apologies to Maven fans if any of this is inaccurate). Ivy requires less of a leap of faith because it fits in with the Ant style that is more familiar to many but still brings the advantages of automatic dependency tracking. It can even install itself.

When I first tried Ivy three or four months ago I quickly found that some of the packages I wanted weren't available in the default ibiblio maven repository, in my case it was BerkeleyDB. I soon came across the excellent Ivy RoundUp repository. Ivy RoundUp doesn't actually host the packages themselves, it's a meta-repository that hosts information on how to download extract and repackage artifacts on demand. Unfortunately I couldn't just switch over to RoundUp because I needed some packages that were only on ibibio, so I had to delve deeper into the ivysettings.xml file to set up what is called a chain resolver. Chain resolvers do just what they sound like they do - they try one repository and then fall back to another if the package can't be found in the first. Here is my settings file:

Unfortunately this didn't work at all. It turned out that the example ivy build.xml in the tutorial contains the line:

  <property name="ivy.install.version" value="2.0.0-beta1">
</property>

And that 2.0.0-beta1 has a bug in it that means that chain resolvers don't work. Once I updated the ivy.install.version property to the latest version (2.0.0 at the time) it worked fine. This is still a problem with the tutorials, so be aware.

Since then I've needed to start using Hibernate in my application so I thought adding it would be easy as it's one of the most widely used Java packages. Err, no. After finding Hibernate in RoundUp easily enough (the latest ibibio version is really old), my build hung for some time, apparently unpacking a file, and then went totally exception-tastic on me.

[ivy:cachepath]
[ivy:cachepath] download.1.N65558:
[ivy:cachepath]
[ivy:cachepath]       [get] Getting: file://C:/DOCUME~1/Jim/LOCALS~1/Temp//jta-1_1-classes.zip
[ivy:cachepath]
[ivy:cachepath]       [get] To: C:\Documents and Settings\Jim\.ivy2\packager\cache\jta-1_1-classes.zip
[ivy:cachepath]
[ivy:cachepath]       [get] Error getting file://C:/DOCUME~1/Jim/LOCALS~1/Temp//jta-1_1-classes.zip to C:\Documents and Settings\Jim\.ivy2\packager\cache\jta-1_1-classes.zip
[ivy:cachepath]
[ivy:cachepath] C:\Documents and Settings\Jim\.ivy2\packager\build\javax.transaction\jta\1.1\build.xml:53: The following error occurred while executing this line:
[ivy:cachepath] C:\Documents and Settings\Jim\.ivy2\packager\build\javax.transaction\jta\1.1\packager-output.xml:28: java.net.UnknownHostException: C
[ivy:cachepath]         at org.apache.tools.ant.ProjectHelper.addLocationToBuildException(ProjectHelper.java:541)
[ivy:cachepath]         at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:418)
[ivy:cachepath]         at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
[ivy:cachepath]         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ivy:cachepath]         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[ivy:cachepath]         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

and another ten pages of related stuff which I'll spare you. There was clearly some problem in downloading the JTA 1.1 classes, which are a dependency of Hibernate. I tried upgrading to the latest version of ivy - didn't work. I then assumed it was an ivy package file and went digging around. When I looked to see the temporary file it was trying to open it wasn't actually there. Hmm. Just before that it implies that it's downloading the file in question. Could it be deleting it? I eventually decided it must be a problem with the file in the repository, so I went looking for help there. That's when I came across this thread on the roundup mailing list archives, and then onto the Roundup discussion of manually downloaded software.

It seems some of the software DOES NOT get downloaded automatically by ivy. Unfortunately, instead of giving you a nice error message telling you where to put it, you get a java.net.UnknownHostException. It turns out you need to download the artifacts manually from the Sun website and put them in the temporary directory ivy uses to store package downloads.

Once it did this it all works magically. Apparently the reason for this is that the download requires ticking a license agreement box which can't be done automatically. I hope this knowledge helps someone save some time. I think in the long run it'll probably mean me having a private repository for those artifacts, but for now I'll leave that for another day.

Dress Code Wars Episode IV: The Suits Strike Back

Wow. What a bit of a crazy couple of days since my last rant on the absurdity of forcing developers to work under dress codes. It hit Proggit, Hacker News, was tweeted by some high-follower-count people, and had more page views than anything else I've done. For those of you new to the feed, welcome!

I've been following the conversation on as many sites as I've been aware of, to try to keep the conversation going, and I was quite chuffed when there were more words on the subject written by !Kirk as by me. Particularly given my verbose writing style, that to me is a sign of a good conversation, which was the primary reason for the rant.

I just wanted to take some time to address some of the common arguments that kept coming up.

Kirk, you're a pompous Prima Donna and you're really not that good, either. Just shut up.

Ahhh, Argumentum ad Hominem. Where would the internet be without you? Just for the record though, I don't claim I'm that good a developer, and while I've been accused in the past of being a Prima Donna, I really don't let it get to me. I think it's more telling about the accuser than the accused.

I like dressing nicely

Bully for you! I'm sure you look lovely in your bespoke suit and custom made shirt. I'm positive you're quite the looker, and are attractive to both genders. You're a straight shooter with Management Potential written all over you.

If you like dressing nicely so much, why are you worried about a lack of a dress code? Why not have no dress code and still wear a suit? If you're just saying that you like dressing well, why not stay dressing well without forcing your sartorial choices on others?

I like South-East Asian food a lot. I think you should like it. But I sure as heck wouldn't have a company cafeteria only sell Thai food, and force you to eat in it every day.

It's better for your career to dress well

Thanks for looking out for your fellow software engineers, and incidentally, I actually agree with this one (if you desire a management role, or a role where you're working very closely with the business on a daily basis, you should dress up a little). But it should be your choice.

This one is an arms race as well. The only way this works is if you dress just a little bit better than everybody else, no matter what they're wearing. Norm is jeans and T-shirt? You wear chinos and a shirt. Norm is slacks and a shirt? You wear a suit. Norm is a suit? You wear a bespoke suit and a custom-made shirt and Hermes tie. No matter what, you always have to dress just a little bit better. You should actually be the most in favor of loosening dress codes, because then you don't have to dress that well/expensively/uncomfortably to still stand out.

Without a dress code, chaos will ensue

"Dress Appropriately" is the most powerful dress code you can have, because it completely eliminates all these arguments:

• People will dress like ragamuffin street tramps. Someone goes too far and you think it affects others? Take them aside and say "that's inappropriate."
• People won't dress up for meetings where formal attire is required. I dress down when I code, but when I meet with investors or customers, I dress up. That's just common sense, and if you actually hire people with common sense, they'll use it.

Fundamentally, we're not children, we're professional software developers. Removing arbitrary rules won't result in a Lord of the Flies situation breaking out.

I don't like seeing your manky feet

Believe it or not, this came up several times. As long as women can wear open toed shoes or nice sandals or whatever, it's just a rubbish argument. You don't like seeing a bloke's feet because you don't usually see a bloke's feet. Believe it or not, there are whole countries where very few people of either gender wear shoes on a regular basis. Get over your foot phobia.

My family needs to eat

Look, I completely understand that your family needs to eat, and if, on balance, the best job on offer is one which dictates a dress code, and you're aware of the likely attitude of the firm based on the existence of said dress code, you should take it. I didn't want a job with a dress code when I took the contract with Big Bank B, but my family needed to eat as well. Pragmatism is the primary virtue of the successful professional software developer.

Just be aware that if the firm has a dress code, in my opinion, that signals many things about the firm and its relationship with its technical staff. Go into it with your eyes open. And in my opinion, if you have a choice between a job with no dress code, and a slightly higher-paid job with a dress code, you should pick the one without the dress code.

Software Developers Should Never Have Dress Codes

On Saturday, I visited my dry cleaner. [1] Normally this wouldn't be a particularly momentous occasion [2], except that it was the first time in three weeks that I had gone. Up until the end of August, I had to make sure that like clockwork, at least every 2 weeks my Better Half or I made the trek to the dry cleaners, to make sure that I had suitable attire for my Cash Money Day Job. But it hit me on Saturday that this was a thing of the past: I no longer work for a company foolish enough to have a dress code for its technical staff.

When I first joined Big Bank B on my 6-month contract, it was the first time I had ever in my life had to dress up for work. I'd managed to work full-time for over 10 years, inside financial services and technology firms, and never had a dress code. In fact, my previous company (Investment Bank A) was so notoriously dress-down for financial services that there was a catty reference in the New York Times regarding the fact that people would (gasp! shock! horror!) show up to meetings in shorts and flip flops. At Hedge Fund V (the previous employer), while traders would usually show up in business casual, nobody cared what the geeks wore. However, the week before I started at Big Bank B, I had to go out and shell out a few hundred pounds on all the things that I didn't have enough of: work shirts, proper shoes, non-denim trousers. All this just to go into an office and code all day.

There's no justification for a dress code policy in this day and age if you view the primary function of a software developer to be the development of software. Right now I'm wearing shorts, sandals, and a T-shirt. Can anyone argue that I'd be more productive (in quantity or quality of technical output) if I was wearing chinos and a blue shirt? Or, perish the thought, a suit and tie? Definitely not.

However, the big question is Why? Why in the world do people still persist with this gross stupidity in this day and age? And why is it that big banks, in particular, seem to be so obsessed with dress codes?

In The Trenches, Fighting Bugs

A few years ago, I interviewed with Lehman Brothers. I noticed that all the technologists interviewing me (and it was an all-tech interview process) were wearing suits. Some of them had ties on, some of them didn't. I didn't wear a suit to the interview, and felt a little self conscious about it. [3] I asked one of the guys there why in the world they were so dressed up to write code all day.

Apparently this had come up in the past, and one of the Really Big American Bosses justified the policy with a phrase that has stuck in my mind ever since: "When a soldier goes to war, he wears a uniform."

There are so many things wrong with that statement that I can't even enumerate them, but let's start with the most glaring: Programmers Are Not Soldiers. Soldiers go to boot camp, a process designed specifically to break down their sense of self and recraft the mentality of the individual to mindlessly obey orders, even unto death. Soldiers go to war; soldiers fight people with weapons; soldiers live in barracks and eat in mess halls and, you know, act like they're in the military.

That's not what I do as a software engineer/craftsman: I think; I discuss; I code; I maintain. I don't live in close quarters with my coworkers; I get to eat what I want when I want; and while whiteboard discussions may get pretty heated, they're seldom settled with bayonets. I don't write code while firing an automatic weapon, and I don't engage in hand-to-hand combat with bugs. How in the world does a standard set by a military organization apply to a private sector financial technology job? [4]

Developers Should Be Heard But Not Seen

Second justification that I've heard for these ridiculous policies actually came from the hiring manager at one of the firms that bought out the carcass of Lehman, maintaining the dress code insanity: "if you ever have to go to the trading floor, there might be customers on there, and we won't want them to see you dressed down." That's right, because someone might see a derivatives trading floor, and figure out that there are actual programmers who make the software that keeps the 8 LCD displays each of the traders have full of blinkenlights.

It reminds me of firms that I've heard of that actually have separate entrances for the IT staff: customers and well-dressed individuals in Door A, all the plebes in Door B (heaven forfend that the twain shall meet). Big Bank B effectively had this policy, in putting all customer-facing activities in one building, while putting all non-customer-facing activities (IT, Operations, Back-Office, Middle-Office) in a whole different building.[5]

Yet most firms that have the separate-door, or separate-building policy, have it in place specifically so that the staff that don't have to dress in a certain way to satisfy the sartorial requirements of outside customers/investors didn't have to. Big Bank B said "not only are we going to shield you from view, we're still going to make you dress uncomfortably."

The Replaceable Engineering Unit

So given that dress codes are a net negative for developers, what could really be behind the correlation between probability of dress codes and size of the firm?

Remember, Big Banks actively fight against entrepreneurial/independent-minded technical staff. And then they make them all dress alike. The two, I think, are inextricably linked by one factor: a desire to smooth out the inherent human differences in employees of a firm grown too big for its management structures to cope with.

The Mythical Man Month was written at a time when almost all developers were working in large institutions, and it speaks to the levels that managers at those institutions will go to try to view individual employees as nothing but entries in a Gantt Chart. It doesn't work, because technologists have different skill levels, different interests, different speeds. But big organizations plan at very senior levels, where the people who are making decisions are unable to even conceptualize the differences between the people underneath them (because they're past the 150-person soft limit on social group sizing).

When faced with the requirement that you manage people beyond your cognitive limits, you can respond in one of two ways:

• Decentralize, and give massive autonomy to the people underneath you whose organizational unit size is within Dunbar's Number; or
• Standardize, and try to force individualism out of the equation.

Let's go back to Lehman Brothers. I think it's actually a telling example, because military units inevitably combine attempts at minimizing individual differences with organizational units that are below Dunbar's Number. So boot camp attempts to minimize individualism at the level of individual troops, but many decisions are made at the level of cognitive limits of social size.

The only way to combine the two though is to have senior executives/military officers making broad-sweep policy decisions ("we're going to start trading Convertible Bonds," "we're going to centralize all treasury activities," "we're going to invade Iraq"), but defer all decisions that rely on the individual skills and proclivities of individuals to the level of managers that actually understand the staff that they have. While many financial technology organizations claim to be applying that principle, ask yourself the following questions:

• Are individual line-level technical leads able to chose the major technologies that go into their software, or is there a central group that specifies the technologies that must be used?
• Are individual line-level managers free to determine the set of methodologies that work best for the team, or is there one over-arching set of methodologies that must be followed?
• Are individual teams able to determine their own deployment strategies based on their technology and the needs of the business, or is there a single policy that determines how software is going to be deployed?
• Do individuals have control over their programming environment (including hardware and software choices, and customization of everything they need), or is there a single image and single standard set of hardware that all developers get?
• Can people choose their attire, when there isn't a valid business reason to dress beyond the comfort level, or is there a dress code that must be adhered to?

My Advice To You

If you ever interview with a firm that has a dress code for techies, don't take the job. And more importantly, tell HR that this is part of the reason you're turning down the job. Because if you are able to find a firm that has reasonable pay, and doesn't have a dress code, that tells you a lot about its relationship with its technical staff. The dress code, on the other hand, is a very clear bright-line test to see an organization that undervalues the individualism that makes strong technologists as valuable as they are.

Plus, working in shorts and a T-shirt is pretty darn cool. Particularly when you get off at Bank or Canary Wharf station and everybody else is dressed up and already sweating at 8:30am.

Footnotes:

[1]: Not the best choice around actually. They're good, but Go Gay just a couple blocks up has a better reputation. However, as I don't drive, the extra couple of blocks I'd have to walk loaded down with lots of dry cleaning trumps an arguably better quality of service.
[2]: I can't/don't iron. When I was growing up, having shirts professionally cleaned and pressed cost so little that there wasn't a point in my parents doing it, and thus they never taught me to. And professionals do a much better job than your house cleaner does (if you're one of the people who has your cleaner do your ironing for you), so the cost really isn't much of an issue.
[3]: Seriously, whoever came up with that whole "dress your best for an interview" advice never had to nip out "for a Doctor's appointment" to interview. I mean, if you're actually gainfully employed, and you don't dress up in your current gig, dressing up is a dead giveaway you're interviewing. So if you do show up extremely well dressed for something that isn't a whole-day interview, it basically says "I'm unemployed."
[4]: I mean, while we're at it, you know who else wears uniforms? Ninjas. And while it's completely Awesome to imagine that we're all ninjas, we're not. If we were, we'd be too busy fighting pirates to get any software written.
[5]: Yep, that means that if you wanted to talk to the people using the software you built, you actually had to go to a whole different building a 5-10 minute walk away. Not that I ever did, mind you.

Hardcore Once More

I've mentioned a few times that I've been working on Something Big, and it's time for me to expose myself a little more publicly. It has bearing on the types of things I'll be writing about, so I think it's time to fill in the loyal Kirk's Rants readership.

As most of you know by now, I moved to the UK five and a half years ago after starting my career in Silicon Valley working for pure-technology startups, specializing in the database and web application infrastructure space. When I moved here, I looked at quite a few early-stage technology startups, but ultimately decided to sell out and work in the financial services area. I did this for a few reasons: London at the time wasn't particularly conducive to working in a pure technology startup; financial services were where the Cash Money was at; and I wanted a chance to build a Next Stage for my career. At the time, I felt that working in financial services, given the concentration of financial technology jobs in London, was the right next step for my career.

Over the last few years, I've run the gamut of financial services firms: I started out in charge of the risk management and analytics software for a hedge fund management group; I was in charge of Front Office Technology architecture for a medium-sized derivatives trading group; I worked as a grunt contractor for a Very Big American Bank.

Am I glad I've done it? Most certainly. I've worked with a great group of people, made great friends, and learned a massive amount about how the financial industry actually works. I think it was the right choice for me five and a half years ago. But it's not the right choice for me now.

Since my 6-months at Big Bank B came to an end on Friday, I've taken the Leap of Faith and have co-founded a technology startup. I've joined the circle from Hard Core Startup Geek to Financial Services Sell-Out back to Hard Core Startup Geek.

I can't say precisely what we're doing at this stage, except to say that along the way I've seen a lot of inefficiencies in the way that financial services firms develop software, and I think that we as an industry can do better. I think that financial services are too important to the global economy, and software engineering is too important to modern financial services, to accept the status quo: not only can we do better, but we must do better. Most importantly, I believe that what we as a startup are doing will help.

I'm joined by two exceptional co-founders, and have a network of other technology startups in London that didn't exist a few years ago. As I've written before, London is now a phenomenal location for a technology startup, and what we're doing we couldn't do anywhere else in the world. If you've been on the fence, take the plunge. London is now a fantastic place to do a startup, and this is a fantastic time to do it.

In short, watch this space.

P.S. Maybe I was too entrepreneurial after all.