[UK-AL]

The whole start-up culture encourages this behaviour. The current fire fast trend, rather than trying find the root cause for example.

Firing someone can completely mess up someones career, but people are being told to fire someone on a whim, if they're not right fit(I mean that could be anything). Turn it around, and put yourself in their shoes.

[_delirium]

It's an odd trend in part because it doesn't seem like companies can afford it. At least, they complain about the results: can't find and keep enough good programmers. If there were a huge pool of easy to find qualified people, just firing people at the first whiff of difficulty, rather than debugging management, could be a viable strategy. But if good people are hard to find, firing a good engineer for "bad fit", rather than first trying to figure out whether the fit is a management issue, seems shortsighted.

Or at least, if you take that strategy, I'm not going to have a lot of sympathy for complaints that good developers are hard to find! If this strategy works at all, and companies really can take a haphazard approach to management and succeed with it, it would suggest that good developers aren't really in that short supply after all.

[marcosdumay]

By the otehr side, not firing can completely mess up a small company, but nobody ever likes doing it.

People repeat a lot of "mantras" that say you should do something contrary to human nature (fire fast, get shit done, speak in a lot public, try to falsify your hipotesis). They are very important, as human nature dictates the default action every time, we need to be constantly reminded that the default may be wrong, and that we should stop and think about it.

But then, stupid people exist, even if they are stupid just a small fraction of the time. And those people will make stupid decisions. There is no procedure, environment, or technique that solves "stupid".

[api]

I experienced "fire fast" on the receiving end once. It's the one and only time I've been let go for any cause from a job. It occurred at a shall remain unnamed big startup on the East Coast.

I was hired on the merit of my portfolio and past positions (I do not have a high-snob-factor college degree), and dove in and got up to speed pretty quick. Job was to implement a lot of Java code and some .NET for a major web-based marketing product. Management was completely by the book Scrum, including actual use of terms like "pigs" and "chickens" and such. I roll my eyes at that kind of thing, but I don't really mind and can just roll with it. It's by no means the worst "management design pattern" you could use.

The place had a superficially awesome culture, even had a foosball table. Roll eyes a little again, but who cares if it's startup-cliche. It actually is fun so again roll with it. Communication in the team feels good, stuff is actually getting done, etc. One person is a bit of a dick but everyone else seems cool. Nice view from the common office window. I feel pretty good about this job so far.

My first and only real hint that anything is amiss is that the code I am tasked with working on is shite. I mean hacky, ugly, uncommented, generally nasty-ass crufty Rube Goldberg machine Java code that takes over a gigabyte of RAM to do trivial things that ought to take under a hundred megs. It's also uninstallable. Just try running it in a dev environment. Seriously. Just try.

I had obviously been given the bastard child of a Red Bull fueled late night coding binge to untangle. That's cool. I'm on it.

My task, should I choose to accept it, was to add a few features to the product and fix a list of several bugs.

Problem #1: this code was so badly written it was incapable of handling the load of current customer demand. Short term solution #1: fire up more EC2 instances. I calculated that for this product alone they were spending almost 1/4 of my salary on EC2 compute instances to compensate for the code's general clunkiness. To do something that ought to be able to be done on a Pentium-4 with a gig of RAM they were running enough EC2 compute nodes to do protein folding on a complete genome.

Problem #2: the code was full of static, global, mutable state. This meant that the easy way of reducing overhead by parallelizing things was an exercise in banging one's head on the table.

I am told this needs to be done. I start feeling as if I'm getting pressure. Sprint is coming to an end soon. Everything I do fixes this or that problem but the boat anchor continues to suck so bad my demonstrations and tests fail simply on sheer bloat. Fucking nasty-ass sack of crap is so bloated I can't even properly test it on my dev workstation.

Fuck it. All weekend coding spree time. I am going to -- wait for it -- rewrite the core.

I stay up late all weekend at home doing this, coding furiously, and by Monday end up with a functional core of this product that does the same thing the old one did but used ridiculously less resources. The old version took many EC2 nodes to do what it did, while the new version does the same thing on less than 512mb of RAM on my Macbook and does it in a fraction of the time. Coffee has now supplanted hemoglobin as a principal oxygen/CO2 carrier in my bloodstream.

Unfortunately I'm going to have to spend a bit longer to get things done by the end of sprint on Tuesday, but never fear. I have cleared my schedule and plan to stay at the office until all sprint tasks are completed, which should now be do-able without wrestling a greased shoggoth.

The meeting is awkward though. I show this to people and I have a strong sense that something is wrong. Later that day I'm called into the office and told I'm being let go, though with a bit of a severance (??? not sure why but I'll take it).

Why?

(1) Performance doesn't matter. Don't I know anything? "Premature optimization is the root of all evil," even if said optimization saves 1/4 of my salary in compute costs and makes the product instantly responsive.

(2) "We don't want to maintain all this new code you wrote" -- but it was less than the old code, I argue, and the old code was... never mind.

(3) My favorite: apparently what I did was "not agile," and I would be "better suited for a research position."

[RyanZAG]

Going to go off the deep end here and say you really were at fault. You can't just rewrite whole systems as a new hire on your own decision with zero buy in from other colleagues or management. While the technology is important in a startup, you kind of tossed the team out of the window there and likely just replaced code that everyone else understood (however bad it was) with code that nobody except you understood.

Basically your approach was terrible and working in a company is more than just producing code. You should have had a chat with whoever had previously been involved in the system as well as whoever in management was in charge of it and explained the issues. They might have told you that the system you had just rewritten was being discontinued in 2 months for a different system someone was making, etc.

I get the desire to just fix any code you come across and it's a great desire to have - but take 15 minutes to communicate with your team - or hell, just send an email before rewriting a whole system.

[api]

I wasn't clear in my OP: there was poor communication on both sides here. I was receiving mixed messages, with the company's VP basically claiming I wasn't able to deliver anything good enough and my immediate boss telling me to kind of punt on the thing. In retrospect I should have dug more deeply. Actually in retrospect I should have started looking for another job, since the VP line-jumping the team lead is a sign of insanely dysfunctional politics.

[candybar]

RyanZag is right that the way you approached this was probably not ideal, but it's quite appalling that the response to a raw display of passion and technical talent was dismissal. They don't deserve you, really.

[UK-AL]

Sounds like a Daily WTF, but it's also very common.

Its seems most companies don't realise the easiest way to move fast, is a extensible, easy to change/understand code base. And not going through spaghetti code with a fine tooth comb. Odd they recommended research, they only care about one off prototypes.

The problem is future employers assume your the problem.

Btw, Proper scrum/agile encourages people to refactor and keep technical debt down.

[api]

Luckily this engagement was so short, and followed after a period of independent consulting, that I was able to be only slightly dishonest and call it a short-term consulting gig.

Thing that pissed me off the most was that I was proud of this code. It was elegant asynchronous java.nio-based stuff that used something like 1/100th the RAM and brought the product's response time down from a several hours "we'll get back to you" to less than a minute for small customer sites. It could also run the entire product on one EC2 compute node instead of like a dozen. I also commented it thoroughly and wrote a design document to hand to other developers describing exactly how its central queue based async architecture worked. Every method had a complete JavaDoc comment including the method's "contract," etc.

It's actually some of the cleaner code I've written. Not the thing I'm most proud of, but probably on the top ten.

Didn't have full unit tests yet, but could have done that in a day or so easily.

The second thing that pissed me off was this: I have a strong suspicion based on circumstantial evidence that the fact that my college degree is from a po-dunk Midwestern school had something to do with it. I have a strong suspicion that what I did would have been brilliant if I'd gone to a top-ten university. The founder apparently had such a hard-on for top-ten talent that he wrote about making sure candidates were from "the right schools" repeatedly on his blog, and I got the sense from the get-go that he was skeptical of my hire.

Whatever. My career is looking good and I can probably code the guy under the table so :P

[bonestamp2]

> The founder apparently had such a hard-on for top-ten talent that he wrote about making sure candidates were from "the right schools" repeatedly on his blog, and I got the sense from the get-go that he was skeptical of my hire.

Fuck these people. I have a fancy degree and I work with better programmers who never even went to college.

I work for a client that is very scrumy and I did a huge rewrite/refactor similar to you one week, although probably smaller considering I also delivered the other tasks expected for the sprint. Nobody even cared that the rewrite made the product 10x faster. Nobody cared! But they were ecstatic about other lame changes that were assigned.

I think it's because management didn't ask for it to run faster, but they did ask for the other things.

The next week I got asked to find out what my changes broke because the app is behaving so much quicker. I had to remind them that I rewrote the slow part and there's nothing wrong. Still, nobody was excited... except me, because now it was a lot easier to develop with because it was faster and easier to debug.

[prostoalex]

> Btw, Proper scrum/agile encourages people to refactor and keep technical debt down.

How? At the place I worked that followed agile by the book the backlog prioritization was done by product owner, who prioritized by the value to the business. Since it was a customer- (and hence sales-) driven business, any trivial change that was visible to the customers ("change subheading to Verdana") was prioritized higher than any refactoring.

Two-week sprints also meant you couldn't really commit to anything that would take two weeks + 1 day.

[UK-AL]

We allocate so many sprint storypoints for keeping technical debt down. That's a fixed amount, immune from interference. The value justification is thst it allows you implement features faster long term rather getting clunkly a codebase. So it does provide customer value.

For long tasks you use a thing called epics.

[davidgerard]

"Btw, Proper scrum/agile encourages people to refactor and keep technical debt down."

http://rationalwiki.org/wiki/No_True_Scotsman

[avenger123]

You may likely just have exposed the team for being incompetents or purposefully building a bad system for job security.

Either way you become enemy number 1 for the team.

Maybe your changes may have been accepted over time but no one likes someone to come in and tell them how crappy their stuff is.

I know that you didn't do this explicitly but that's the message that comes across.

[brown9-2]

It's a really bad sign when people look at the end of the sprint as an absolute deadline for things needing to get done.

[api]

In this case my part of the sprint probably would have run over by one day, since I had one more feature to implement around the new core I had written and I had to spend extra time refactoring code for existing features a little (not too badly) to make them work with said new core code.

The logical thing would have been to punt that one feature, make everything else work (it was very close), then spend the rest of the sprint testing before swapping the old boat anchor out. Either that or keep the old version in place until the end of the next sprint to give time for complete unit tests to be written.

[brown9-2]

Was there seriously no one there that appreciated the AWS cost savings?

[api]

Apparently the fact that I had "rewritten something for performance" was viewed as an inherently bad thing to do regardless of the rationale or benefit. That's because some smart guy once said it was "the root of all evil," and everyone believes smart guys who are quoted a lot.

I really have a pet peeve about cargo cult thinking in general. Concepts and ideas have context. To me it's a sure sign that I'm dealing with an impostor who does not actually understand their subject. Yet another reason losing that job was a blessing in disguise.

[Kurtz79]

Great story, thanks for sharing.

In a way, it was for the best, isn't it ?

It is clear that you weren't a good fit for their development team and their interpretation of "agile" software ...

[UK-AL]

Yes but it can quite easily end up disaster. When you get a new job, what is the first thing they ask for? References.

[Kurtz79]

I agree that there is a stigma attached to being "fired", but in the real world it's something that can happen, for reasons completely unrelated to one's worth.

For someone with a solid portfolio and demostrable previous experience, something like that should be nothing more than an unfortunate aside.

[walshemj]

That is why companys tend to give brief factual references so that some manger doesn't go off on one and land the company with a big lawsuit.

[pekk]

Except if they don't. It's not at all likely that whatever they say will get back to the candidate, let alone in a legally actionable form.

[walshemj]

Well normally you get the offer only then do you give them your references - get knocked back the then you get your layer to get the papers from the section process.

Now Mr HR manager lets say 30k for a compromise agreement shall we and you fire the person that decided to accept the libelous statement for my ex employer - and when do I start :-)

[dmajoraddnine]

Very interesting story.

Looking back, did you feel like you were fully communicating your situation to your team? What did your manager say about your concerns?

[api]

Yes and no.

I attempted to communicate the fact that something would have to be done about this code base if it were to scale beyond "beta," and talked a bit about making this an official part of the next sprint. The decision to do a barn storming run was a result of pressure and mixed messages. I was getting e-mails from the VP (not my direct boss) sort of implying that I was being slow and that my performance was not satisfactory.

In retrospect I may have walked into a political trap, but it's cool because I don't want to work for a company with politics like that. I also think in retrospect that there was poor communication on both sides. I didn't communicate the issue quite clearly enough, and they didn't communicate their priorities clearly enough. I also think getting mixed messages from different people above me in the company hierarchy really confused my sense of priority. If I hadn't gotten that I probably would have just done what I could on the issues at hand with the strong recommendation that the core be rewritten and moved on to the next sprint.

[a3n]

Are they still in business with prospects for success?

[api]

Yes. They are actually a fairly hot company on the East Coast.

In retrospect I do realize this: they are not a tech company. They are a marketing company. They have a couple cash cow products and their audience doesn't care much if they're slightly rough around the edges. So in a sense I was polishing their product in a way they did not think was important. I disagreed -- personally instantaneous response times are a big selling point for me and I did point out the hosting cost savings which were non-trivial -- but I was not the boss so that's how it goes.

[UK-AL]

This is a brilliant story, and reenforces the problem start up culture atm.