The shittiest project I ever worked on (2013)
449 luu 12 hrs 201
https://blog.plover.com/tech/prudential.html
news.ycombinator.com/item?id=19998806
bonoboTP 4 hrs
Having followed HN and similar dev culture (Dilbert etc.) for some time now, I feel a growing contradiction that I cannot fully resolve.
On the one hand big corporations are presented as these incompetent behemoths that are locked in their internal petty office politics, managers are clueless as to what is being or should be developed, and tons of money is wasted, they are wooed by empty marketing etc.
On the other hand these organizations are immensely wealthy and successful.
It may actually be that they are right, and for non-tech-centered companies this whole software stuff is really peanuts and their mental energy is better spent on other business-related stuff. So they will come up with random low-effort comments on all sorts of details because ultimately they (rightly) don't care. What actually matters is to negotiate deals like referral fees, or coming up with other contract ideas that will bring a lot of revenue in.
Or maybe it's just an equilibrium, a local optimum. You don't have to produce "good" stuff (in the developer's sense) without waste, precisely because the other company that you're targeting is also inefficient in similar ways.
I'm really not sure but I think it's important to look beyond just "haha, stupid managers, they can't make up their mind". There must be deeper reasons.
CPLX 3 hrs
I've had this same thought, and have a pet theory about it. I think the answer is something like momentum is so unbelievably useful in business that having it is enough to be immensely wealthy and successful.
As someone who recently created yet another startup, I am reminded daily that literally everything I do has to be done for the first time. It's like molasses covering every part of the machine. When a client needs a proposal you have to write one from scratch, when someone wants payment terms or to negotiate a contract adjustment you have to figure out contract language. You don't have expense reimbursement forms, you don't have job descriptions, you don't have anything to use as a starting point or template for anything you do.
Big companies have all that. They have clients that are planning on using them again this year. They have meetings they took two years ago that are about to be a sale. They have a guy on the third floor that has seen this problem they're about to have once and knows how to avoid it. People instinctively trust them, so they don't have to explain themselves as much. People instinctively fear them, so their contracts get upheld. People that used to work for them now work at potential customers and call them up.
And on and on and on. Having a slightly busted software development process is, in fact, peanuts compared to all this.
Or, perhaps another way to say it is that there's a lot of different kinds of "software" besides the digital ones-and-zeroes kind we think about here. A group of humans all organized around a business purpose with tons of experience and momentum is a high functioning machine as well.
rossdavidh 3 hrs
This theory, by the way, explains why efforts to turn around failing large companies are so rarely successful. Once that momentum is a bunch of bad decisions, etc. the momentum is working against you. But, up until that point, it is extremely powerful.
amelius 1 hr
It's not just momentum in that sense; it's also the fact that wealth begets wealth. (Which you could also call momentum in a way.)
tmaly 1 hr
This idea of momentum reminds me of Jim Collins Flywheel Effect
https://www.jimcollins.com/concepts/the-flywheel.html
I have to disagree with the broad statement that a busted software development process is peanuts. In highly regulated industries like finance, bad software can cost you billions in fines from regulators.
In these industries, they have to invest in technology and good processes if they want to stay in business.
w0utert 1 hr
High-tech is similar. Where I work there are literally 100s of insanely bright people with backgrounds in math, physics, etc. who struggle for years to get their ideas into results and (ultimately) products. Usually things get stuck on simple software tasks like connecting things together, driving them in a feedback loop, or just identifying that all the parts are already there, scattered around the company, and someone just needs to write a framework to put them together. I honestly think huge business opportunities are lost because of inefficient software development processes.
In a sense, this lends credence to the theory that once you’re big and powerful and have lots of clients, you can afford to lose these opportunities. But I still think that you would have a huge competitor advantage without all the molasses.
PhasmaFelis 34 mins
What is a "comparison company" in that article?
linuxftw 2 hrs
Good analysis.
I think for software sales, this type of thing is slowly fading as it becomes more and more commoditization. For all but the largest of businesses, you go to AWS and pay the market price for compute and other services, there's not much need for contracts and negotiations and meetings, the price is the price. Going to a competitor or doing business the old way simply costs much more. Eventually, businesses align on consuming commodities as commodities, the spending slowly moves from CapEX to OpEX.
AWS is the power company now. You agree to their terms, and you pay their bill. Unless you're doing a major industrial facility that requires mega-watts of power, you don't need to interact with their sales staff; same applies to AWS (and ironically, you can probably use power as a proxy to relative deal size here, too).
100 years from now, all the conceivable software is going to exist that could exist, at least for 'business processes.' If your business is selling potatoes as a farmer to distributor, the software you need to participate efficiently in that market will already exist.
nullwasamistake 1 hr
The upper end of the market is still contracts all the way down. My company has around 250 employees and every single service we use, software and otherwise, is a negotiated old school contract.
The market price isn't what most companies pay. If you pay significant amounts to Amazon (maybe 1 employee salary worth) you're screwing yourself if you don't negotiate lower rates
Edit: Just asked the corporate overlords. It's actually against our finance rules to pay for any recurring service charge without a negotiated contract.
luckydata 1 hr
You're still paying market price, just not the published one. Negotiating b2b deals is a little like ordering from the secret menu at in&out. Doing tons of that lately and it's quite the mechanical endeavor. The only really annoying part of it is deals move only as quickly as the sales drones want it to. I have to sit through their "sales process" even if I know exactly what I want, I know what I can spend and ultimately the deal will be done on my terms. It's funny to think that some guy got high fived to death for selling me a contract for about 35% the original quote.
madhadron 1 hr
It's actually against our finance rules to pay for any recurring service charge without a negotiated contract.
Your company probably also employs a professional shark whose job it is to squeeze the blood out of every stone he is pointed towards. With even a modest number of sizeable contracts, such a person would pay for themselves very easily.
mruts 49 mins
At my old company we were paying millions for contracts and software we didn't use or really didn't mean. One of the analysts volunteered to be the "undertaker" and renegotiate. After a year of screaming at people on the phone (I sat next to him), he managed to save us around a million dollars, which was around a 60% savings. He pocketed maybe 30% of the money saved that year. Not bad for a year of being a dick.
Spooky23 31 mins
The Dilbert perspective is a shallow one.
End of the day, a big company or government agency is too big for any human to internalize. It's a machine that pumps out process, but the downside of consistent process that change is more difficult.
When I worked at an agency that supported social services, some guy was bitching and complaining about how everyone who wasn't him was stupid, the agency was awful, etc. One of the more respected directors walked by and heard this. She popped in and said something like "There are x million people who depend on us to feed their children. And y million people who expect us to do so in a responsible and equitable way. We've never missed a payment, ever, because of this team."
Another example is the military, which is probably the dumbest possible bureaucratic institution ever devised. Yet is capable of executing the mission with ruthless efficiency, and can survive in the face the adversity and loss that few organizations can.
Smaller organizations are always better at reacting to change, because there are fewer stakeholders. But, they suck at many things, including consistent delivery, paying things on time, and organizational resiliency. Software makes them better, but software is its own form of bureaucracy with its own set of problems.
blauditore 2 hrs
I think success doesn't come because of these bad decisions and red tape, but despite them. I have the impression that in many areas, a certain "critical mass" makes a big difference, e.g. more market presence may generate a lot more sales even if the product is mediocre.
I still think that doing things the right way and getting rid of those famous inefficiencies could leverage success even further. With regards to software I think that's the difference between large companies with a known engineering culture (like Facebook, Google, Apple, Microsoft) as opposed to those known to be a bit more red-tapey (like IBM, Adobe).
But of course, "doing things the right way" is terribly hard to quantify, and so is "how much success would be possible". If numbers at the end of the year are already positive, good luck trying to convince C-level to introduce fundamental changes to existing processes.
org3432 1 hr
But of course, "doing things the right way" is terribly hard to quantify
I don’t think it is hard to quantify actually, shorter build times are better than longer ones, branch merges that take seconds are better than the ones that take up to a day, spending people’s time on higher level thought processes vs squandering their time going through pages of manual steps that could just be a script, etc. It’s just a lack of awareness of what the company is doing that turns them into molasses, and puts projects at risk of being canceled. The companies are still successful overall somehow, but individual employees learn and grow at a much slower pace than they’re capable of.
twblalock 2 hrs
These organizations succeed because these inefficiencies are not the result of incompetence, but the result of prioritizing other things that have a bigger impact on the bottom line.
Software is viewed as a cost center at a lot of companies, and in many cases that is the correct decision. The company officers and managers understand this, which is why they act the way they do.
Their goal is not to make the best possible software -- it is to ensure the software is good enough that it does not hold back other areas of the business, and to achieve that within the budget they are given.
azhu 2 hrs
There is a phenomenon that happens when things scale. A certain level of detail begins to fade into static fuzz around the edges.
Think about the difference in terminology between a coach and players. When a coach takes a team through a play, they usually don't tell the players which hand they need to dribble with or which foot to plant first when running, they use much broader strokes and leave the implementation details to the player.
Let's take the example of... perhaps a Jamaican bobsledding startup. In the early days, you don't know what you're doing so everything matters. You scrap to purchase airfare to get to key industry events so you can be where the players are. If you mess up almost anything, it's game over. But you make it there, and you perform like you knew you could. You pick up sponsors. Expenses like airfare are now no longer a problem. What before used to be a mad scramble to organize and scrape together funds and make sure you have a good pitch for the big meeting is now a smoothly oiled proven machine with accounting and assistant cogs. Your jerryrigged home workouts are now streamlined by an Olympic training facility. Your mind is now no longer occupied by what has become minutia to you. You don't really worry about grocery shopping because you have a team nutritionist. You don't care about how efficiently or inefficiently the process of grocery shopping and cooking goes down now, just that it does and is on time.
You no longer make music with an instrument. You conduct an orchestra. Your mind is now thinking in bigger blocks.
Software is just one section of most orchestras.
rossdavidh 3 hrs
Actually, I have seen small companies do just as badly at things, but they don't stick around for long, because they die from these mistakes. The ones that CAN make mistakes like this again and again, must be huge, and also their mistakes are more visible because they're big.
Plus, small companies that make big mistakes that do survive, are scarred by the experience and tend not to repeat that particular kind of mistake again. Companies that can make a blunder of the sort described in this story, repeatedly, have to have been big in order to survive long enough to repeat it.
jldugger 29 mins
IMO, the way to resolve this paradox is to realize that the equilibrium adjusts slowly, then all at once. IBM is a pretty clear example of your clueless behemoths. On the other hand, their net income per employee is now closing in on like $24,000 annually, which sounds good, until you realize it was $29,000 2 years ago, and Apple is around $600,000 and Facebook is around 2 million.
IBM will continue to target their most expensive employees for layoffs while hiring cheaper new grads, but even after those alleged practices, their profit per employee fell by 5k. Seems reasonable to expect they won't be around in a decade, though I'm no financial expert and this is a projection from two datapoints.
mdpopescu 3 hrs
Large companies are inefficient because they suffer from a number of problems (calculation, internal politics, Peter's principle, Parkinson's law and so on). However, they can introduce savings due to lengthening the production process, economies of scale, (external) political power and other factors.
The fact that a large company is rich does not necessarily mean that the inefficiencies don't exist.
I somewhat agree with you on "this whole software stuff is really peanuts and their mental energy is better spent on other business-related stuff". For most companies this software stuff can be mostly irrelevant, and it's our fault this is the case. As Erik Dietrich says [1], we are "efficiencers" -- we're supposed to make all kinds of processes more efficient, not just be code monkeys and copy code from StackOverflow.
[1] https://www.amazon.com/dp/B0722H41SG/ref=dp-kindle-redirect?...
rjkennedy98 3 hrs
Having worked for a while at one of these enormous companies I will take a stab at answering this:
Tech is an afterthought for most of these companies. Most of them are natural monopolies. Insurance for instance is a business that works such that the larger you are the lower the risk and cost. Take the ACA: many nonprofit startups tried to join the ACA marketplace to compete with the Big Boys. Essentially all failed.
These companies have so much money that they can afford to do things like 10 million dollar POCs (which I've seen). Often they have literally 5+ different teams doing the same exact thing and will pick the best out of that list.
In some cases (I won't say which) they essentially launder profits through the "tech" parts of the company. They basically optimize for cheap people they bill out to the "real" company at some enormous fee.
wool_gather 1 hr
These companies have so much money that they can afford to do things like 10 million dollar POCs (which I've seen). Often they have literally 5+ different teams doing the same exact thing and will pick the best out of that list.
Ugh. Reading stuff like this gets me deeply sad; what could have been done with that money and time instead? It makes me want to go escape to live in the hills, maybe even a full-on Wonko the Sane.
groestl 1 hr
Don't forget that capitalism (with companies), and life itself does things that way. It's not necessarily elegant (although some might say it's actually elegant), but it works.
ambicapter 3 hrs
In some cases (I won't say which) they essentially launder profits through the "tech" parts of the company. They basically optimize for cheap people they bill out to the "real" company at some enormous fee.
Can you explain this differently? I don't understand how you would launder profits through yourself (or why you're laundering them at all-tax reasons?).
ekianjo 1 hr
i guess outsourcing the actual work for very cheap and charging the end client a much higher amount. very common.
scruple 1 hr
It's perplexed me, as well. What I've learned over the years with my current company may have an insight. When I joined, we were 50-100 employees. The tech was good. Revolutionary, in it's context and industry. We were actually doing something useful and good and positive for other people. In the last 3 years, however, we have seen tremendous growth. We're now closer to 300 employees, if not more. The tech is less revolutionary. We're now in an innovation through acquisition phase.
What I see is: most of this new cohort has no idea what our business is and they are overwhelmingly concentrated in middle management.
kouh 1 hr
Reminds me of Microsoft. They only had two engineers working on MS-DOS 1.0, their most important and profitable product at the time. Despite recurrent industry criticism of the product and the launch of competing DR DOS (faster, better and 33% the price), it took Gates two years to react, with commercial tactics first (and eventually overdue product changes later)...
Source: http://www.ariplex.com/tina/tcfact01.htm
carlmr 59 mins
My take on this: you're right that the other large competitors aren't better. That's just basic economics you only get good enough to be close to your competitors.
The other side is that a large company often gets large contracts. If you sell a software 10 million times it doesn't really matter if you spent 100x as much on it as a small company would. The small company with 10000 customers still is having 10x the revenue per work done.
Could you make more profit? Sure, but lacking market pressure you're rarely concerned with efficiency.
I just noticed my company always books flexible airline tickets. They cost about 2x as much as non flexible ones. I've never missed a flight and most of my colleagues haven't either. It makes sense if you're a busy manager that often doesn't fly. But for most engineers the flexibility costs more than what it's used for.
jordanbeiber 17 mins
I believe that this is what the "digital transformation" is about, for real. I'm not even joking.
Only a wealthy company can spend $400.000.000 on an SAP project, for example, but in reality it would probably be better for the business long term, to build something custom and embrace the fact that IT & tech is important to achieve its goals. If it's not, why spend the money?
Doing it right probably means creating a "software factory" or tech hub within or outside of the company.
If we're talking a company with muscle and will to plow down $100s of millions on a massive tech/automation project, this should be feasible right?
For an example, see Lufthansas tech initiative: https://lh-innovationhub.de
(I'm not in any way affiliated to LH, I just happened to read about it a while back, while trying to convince my then CEO that something like that probably would be better that spending millions on proper crap from 3rd party)
I'm sure there's many other examples.
Traditionally, the problem is that with money comes politics. Everyone wants a piece of this pie, and a lot of non-tech/dev employees are used to turning to vendors.
The thing is, what you want to achieve is a cultural change, not simply an organisational update (which is why, in the LH case, the tech hub is not located at LH HQ. It is not a cultural match, according to the CEO).
Does this change even require money, except salaries for the "right people"?
Big business have done IT & tech a huge disservice by outsourcing and off-shoring things not considered "core business", such as tech & coding. The pendulum is swinging, at least in my experience, and suddenly everyone need dev expertise again. Of course they do, because most likely you will be disrupted by a company without the legacy, that is sprung from tech.
Well, not a disservice to us still around, but it's obvious that theres a lack of expertise to just pick up off the streets.
How long you can keep a lot of people employed in a traditional IT dept. and buy a lot of half-crap vendor solutions that you glue together in half-assed ways I guess depends inertia of you customer base, and also as pointed out below, already accumulated wealth.
scarecrowbob 3 hrs
"I'm really not sure but I think it's important to look beyond just "haha, stupid managers, they can't make up their mind". There must be deeper reasons."
You might take it as evidence that, of all the myriad aspects of a business, scale far outweighs all other factors for generating a profit.
You don't have to be "good" (whatever that might mean) to generate profit, production costs just need to be marginally cheaper than your prices.
org3432 52 mins
The managers and directors if you talk to them will frankly tell you they have no idea what’s going on, they hire people and somehow the problems they were hired to solve don’t get solved. I had a founder tell me he created an entire department to improve the developer experience and nearly 20 employees later they’ve not made any successful improvements, they just limp along the broken systems.
NateEag 3 hrs
In most cases, the large companies being picked on as "not knowing what to develop" are not software companies. They make their money from selling things or human services, not programs.
If software is not your core competency, you don't need to be any good at it to make money.
ashelmire 44 mins
From my observation, these companies become wealthy and successful first, then develop awful cultures as innovation becomes less important (and more difficult as you get away from your core business), and extracting maximum value from current capabilities (sales) becomes more important. Once you get to making billions of dollars, your organization can afford to be a lot less efficient and less innovative technologically.
CM30 1 hr
It's a mix of things to be honest. For instance, you're right, for many non tech centred companies the software stuff isn't all that important.
Hell, in many situations in general it isn't that important, since knowing the right problem to solve and who to market the solution to often matters a lot more than the technical quality of the solution in question. People and companies generally don't judge products and services by code quality or development practices, and unless these cause it to constantly break, don't really care about them at all.
But other factors do matter here. If a company is a known brand, then they can keep getting customers for terrible products for a long, long time, simply because they're the first name people go to. At some point you become so big, you get so much momentum, that you can basically publish/release anything and people will buy it. Apple could sell the most broken phones on the planet, and have 10 million + people rush out and buy every one.
Do companies get away with it forever? No, but the bigger you are, the longer it takes for you to fail after your products/services become crappy.
And yeah, as you say, local optimums matter too. If most companies in your field are inefficient and put out terrible products, then there's not much pressure for you to be much better.
paulddraper 4 mins
I will invoke the Peter Principal [1], but for businesses.
These now big corporations were really good at something...so good that they beat the competitors, grew their market share, expanded their head count, etc.
However, operating at a higher and higher scale (or with more modern technology) brings new challenges that weren't part of the game before. Ones that they are not necessarily good at. Eventually they might become great enough to threaten the company itself (AOL, AT&T, Yahoo, etc.)
The inefficiencies you see are characteristics that have be acquired due to the level of success and exposure to new challenges. The inefficiencies are not characteristics that got them to that success.
[1] https://en.wikipedia.org/wiki/Peter_principle
Quarrelsome 45 mins
On the other hand these organizations are immensely wealthy and successful.
Have you read "Searching for Stupidity"?
Basically the NASDAQ of 1990 has almost no relation to that of 2000 not because of competence but of stupidity. Big lumbering behemoths shoot themselves in the foot and fall over.
collyw 1 hr
I worked for a large investment bank a good few years ago. It was probably the crappiest job that I have had in terms of job satisfaction. There was a high staff turnover and the answer was to throw money at the problem and keep the churn going.
It seemed to work for them.
kevstev 2 mins
I also worked at a few IBs before I came to the realization that one was just worst than the next. I thought that they worked by underpaying people just out of school, but dangling the carrot of big bucks that always seemed just out of reach (maybe next year I will get the big bonus!) and then churning and burning.
I am back in finance at a private company, and I am part of our on-campus recruiting efforts, and I frequently tell candidates "listen, take a job with one of our direct competitors, that's fine, but whatever you do don't take an offer at an investment bank if you can avoid it- they will just work you to death largely filling tech debt and you won't get the opportunity to work with the truly best and brightest..."
rb808 1 hr
There are some bad organizations, but overall most are not incompetent behemoths. Yes a little website for a startup that gets a few thousand people doing trivial things is technologically much more advanced. But when you get involved with millions of customers are lots of complexities that make everything complicated.
whatever_dude 3 hrs
I think it's more likely that they stumbled into a profitable position in some market or another, and that became their bread-and-butter. Being successful for a long time breeds incompetence.
badpun 2 hrs
To be successful in capitalism, you don’t need to be awesome - it’s sufficient to be no worse than competition. And the competition is the same huge, kafkesque mess - primary because no one yet figured out how to organize thousands of people without creating inert beaurocracy in the process.
aidos 8 hrs
Not me, but one of my favourites would be when a guy joined our team. We were an agency and he’d been hired by the client to eventually take over. On the first morning I walked him through the codebase and showed him how it all worked, how to extend it etc. After a while I said “any questions?” He replied, “yeah, just one - am I meant to be a developer?”
Turned out that when the startup had brought him in as CTO they failed to mention that he was eventually going to be the sole developer.
weka 4 hrs
Gotta ask -- how did the next few weeks/months pan out?
aidos 1 hr
To his credit he just kinda sucked it up and got on with it. I was happy because eventually I didn’t have to work on it anymore. Surprisingly, all the money they wasted on buying rack servers and Oracle enterprise licences didn’t net them more than 10 visitors a day and it feel apart. Once it all went pop, him and I crossed paths on other projects too, got to trade stories about the absurdity of it all.
jawilson2 4 hrs
So he was the OTO - Only Technical Officer
TheRealDunkirk 3 hrs
He got catfished.
I'm feeling it, because I was recently catfished.
stanleydrew 3 hrs
What does catfished mean in this context? Mislead into a role you aren't suited for?
pault 3 hrs
Accepting a job offer based on a false representation. Usually by offering you an inflated title and promising responsibilities and opportunities you won't actually have.
Double_a_92 2 hrs
Like when you get the Big Data Analyst job, but you are actually supposed to create plots from Excel data and put them in some sales Powerpoint...
linuxftw 2 hrs
Oh, that sounds so brutal. Had no idea this was a thing that happened to people. I would-first week quit.
komali2 1 hr
My buddy quit a senior developer role day 1 at Walmart labs because they sat him down and presented him with the task of doing nothing but technical writing.
bshimmin 8 hrs
I think anyone who has done any consulting with a big organisation probably has one of these stories. As one of the other commenters says, if the end result is something that the client is happy with, and they actually pay you, you should basically consider this a success!
I spent six months building a single-page app (back when that was still an exciting sounding thing) for a major US financial institution; by the time we actually delivered it, the result was so watered down from the initial proposal that I could've just taken some screenshots from what my designer had produced six months earlier and put them in a PowerPoint deck and said "Done!" - because this was, in fact, what the VP at the company ended up doing, except they were screenshots from the web app we built that no one other than the VP himself ever used.
On the plus side, I became good friends with the VP and the project paid off a significant chunk of the mortgage on my first house.
pault 3 hrs
As an aside, I sometimes have to play UX designer when there is no one qualified available, and I've used every wireframing tool in the market trying to find something that allows me to create UIs as quickly as I can think. A few weeks ago I gave up and in frustration I put together a quick powerpoint so the product team could work on it themselves. It turns out PP is exactly what I was looking for! I found that all the other tools required a lot of setup and configuration that slowed me down, and powerpoint is so simple that you can just start plopping squares down on the page and put a few links in-between slides. I think the real gain for me is that most products I work on end up being data grid heavy, and creating tables in balsalmiq/whatever is always a nightmare.
Double_a_92 2 hrs
Yeah, Powerpoint is a surprisingly good drawing tool. I remember in college a lot of my classmates used it to create illustrations for their thesis.
Jedi72 8 hrs
Good thing there are no real problems left to work on in this world or this would be a gross mis-allocation of macro resources.
(No judgement on you OP this is the situation we're in)
clarry 6 hrs
Ah but if someone paid for it, the problem must be exactly that valuable to them! And if it's valuable to someone, it must be a Real Problem!
weka 4 hrs
When it comes down to it, we're not paid to code. We're paid to solve problems with code and if paying you $75/hr as a contractor to build me three webpages with CI/CD capabilities is it, then off you go.
pault 3 hrs
$75? That's about half of what I would charge myself, and an agency is going to be $300 minimum.
azhenley 4 hrs
They needed this developer to help them understand what they needed. Every project I’ve worked on (even personal projects) has a fair amount of this.
soVeryTired 3 hrs
Out of interest, do you mean that seriously or are you parodying the sort of knee-jerk reply that an economist might produce?
wool_gather 1 hr
Personally the capitalized "Real Problem" (along with my current mood) makes me lean towards sarcasm, but yeah, Poe's law...
mekkkkkk 6 hrs
The whole point of all of these stories is funny/sad misallocations of resources. The "real problems" thing is a completely unrelated discussion. Not sure why you'd want to weave that in.
airstrike 4 hrs
He's weaving it in because the parent called it "a success", which is only true from your individual perspective, but not from a societal one. And some people want more from what they're doing than just personal gratification.
asveikau 3 hrs
I agree that our definition of success should have a strong societal component. However, if you expect societal benefit from every action, including actions heavily dependent on something like the whim of a consulting client, you may be faced with a lot of anxiety when you inevitably fall short, anxiety which may ultimately hamper your later individual capability to achieve societal benefit.
mekkkkkk 3 hrs
I think you might be overloading the word "success". A successful project doesn't necessarily imply anything beyond delivery of what was agreed upon.
pbhjpbhj 4 hrs
Did he even get personal gratification, he got paid handsomely (by the sounds of it), but it didn't come across as him feeling fulfilled beyond that.
bshimmin 3 hrs
I can confirm that I both got paid handsomely (especially for the second phase of the project where we were on a retainer and literally did one day of work over the course of three months, barring a couple of phone calls) and that I felt very little satisfaction or gratification at the end of it, especially when the whole thing we had built was eventually rebuilt by a different offshoring company using a much clunkier technology stack without so much as a glance at our code.
I stand by my original assessment that, from the perspective of both the client (everyone was happy with the end result) and my consultancy (we delivered work and we got paid), it was a success.
vibrato 4 hrs
This kind of misallocation is really the only thing keeping velocity of money high enough to sustain the economy
wool_gather 1 hr
While I don't necessarily disagree with the conclusion, I think it's worth questioning the unspoken premise here:
Is there no other way to support human life than these accelerating grinding gears of money-shuffling?
chii 4 hrs
Or those losses the only thing preventing the creation of even greater things
vibrato 16 mins
Well, of course. Problem is that, apparently, we're doing the best we can.
pbhjpbhj 4 hrs
Could you expand that a little for us slowpokes?
Aside, I assume you mean "to sustain the [USA] economy"? Perhaps you mean World economy, or EU, or ...?
Balgair 31 mins
Oh dear God ... I just finished this exact project this week (ok, 90% similar)0, everything he says is true.
The insanely messy data (bathroom intergers are a mess!), the firm essentially being just a collection of smaller firms in one building, the massive issues with 'finder fees', the near endless list of VPs that have to pass anything off, the contractors not knowing anything, the 'real' employees also not knowing anything, the hosting of websites, the brokers paying for useless (to them) web-dev, it's all true! Nothing has changed in ~25 years!
0 I know you're reading this Jeff.
SubuSS 59 mins
These are the instances where I feel it is definitely worth keeping some people around who act as glue. (or old timers).
In our company - we have a tech lead role which is supposed to be the technical point of contact for a given team. This person is expected to have answers or have a way to find the right answers about the nuances of the team.
The good ones are invaluable. Whenever new projects come up, the modus operandi is to write a proposal, review it with your current team for sanity (on whether it achieves its purpose) and then with this group of relevant stake holders / tech leads to ensure you're not getting some giant thing wrong that can nuke some other part of the business.
The problem I see with this role though - we (I am the one for analytics and one of the TLs for Data Infrastructure at Snap) have to handle 20-25 hours of meetings around all these coordination AND ensure some work gets done in your own area so that you are in touch with the code bases you are fiddling with. So as much of an alluring title that is, you are giving up deep dive development (like I was able to do building storage engines for DynamoDB). Tradeoffs :/
And there are cases where the tech leads don't have the answers (new or incompetent) OR they think of a weird case couple of months down the line, but this works out overall.
I probably should write a blog about this - but anyway, I don't know how this works out in the non-software world: Why wouldn't you have a knowledge person/council around?
sequoia 26 mins
The problem I see with this role though - we (I am the one for analytics and one of the TLs for Data Infrastructure at Snap) have to handle 20-25 hours of meetings around all these coordination AND ensure some work gets done in your own area so that you are in touch with the code bases you are fiddling with.
If you figure out the answer to this PLEASE share it with me. This describes my current role; whenever I focus on one aspect (eg actually writing a few lines of code) the other (keeping up with planning) suffers.
My suspicion is that “tech lead” in this context basically means “manager,” but employers know many devs are scared of the word manager, so we have the highly ambiguous “tech lead” title, which allows dev managers to be in denial about their actual role.
seanwilson 4 hrs
The report I got about the demo was that the real estate people loved it, it was just what they wanted.
“But,” they said, “how do we collect the referral fees?”
This is why you need to understand what problem a client wants solved and not just build what their suggested solution is. Even if you build their suggested solution perfectly, they're not going to be happy at the end if their original problem isn't solved. Their suggested solution should only be used as a starting point to understanding their requirements.
JoeAltmaier 3 hrs
That's a confusion about who the client is. This was a web page, to be used by a public consumer. The real estate people were, in my view, obstructionist old-guard trying to preserve their paper empire. Not the client. They torpedoed an early example of the web removing the middleman and streamlining an industry. Prudential's agents weren't ready for the revolution.
seanwilson 3 hrs
Isn't that a lesson then that you should make sure you're talking to and getting buy-in from decision makers higher up the chain instead of people whose decisions are more likely to be overturned?
jimmydddd 3 hrs
Hypothetically yes. But in some cases, you are hired by a department in a large division of a huge corp., with many layers of management above the department that hired you. And the end product is for a department in a totally different division of the corp. In such a case, you don't have access to the actual end customer.
wool_gather 1 hr
The right move at the point where it got presented to and rejected by the other division was probably to say "Well, I built what we agreed on. I'm happy to revise the product based on this external feedback, but that's not included in the original fee".
But the article did say that this was at a point in his career where he might not have been experienced enough to make that call.
seanwilson 2 hrs
Why wouldn't you be able to get access to the end customer to validate what you're building?
oblio 1 hr
Because he's not the one paying you.
c3534l 10 hrs
This... this is just my life right now. Get a contract, spend all of my time doing anything other than actually accomplish anything, and then after wasting time adhering to project requirements that don't make sense, wind up delivering something that could have been done in 10% of the time if people listened to me at the start of the project.
rubber_duck 8 hrs
wind up delivering something that could have been done in 10% of the time if people listened to me at the start of the project.
I felt that way until I eventually got to a point where people did listen - and it turned out to be false. I underestimate the effort required on first glance and I oversimplify things in hindsight. Also I'm a developer - not a business guy - I can guess a lot of things on the requirement side but a lot of it is outside of my domain. This is something that I have to be aware of now when I'm in a position to give such estimates.
Don't get me wrong - I think there's a lot of room for improvement in almost everything I worked on before and after me - but that gut feeling of how I could have done things was never on point for me. With the article in question - too many people involved in the decision - no way to know the final result for sure until people see it have a bunch of meetings, see the iterations and decide on this - rarely do you have the person with deciding power know/understand these things clearly from the start. And you need to account for bureaucracy BS time-waste - it's just a fact of life when dealing with such clients.
hamilyon2 4 hrs
Your comment was something like eye - opener for me.
haskal 9 hrs
Start a consultancy, name it (or if you have one, rename it to) Cassandra0.
avar 8 hrs
And in keeping with the spirit of the article charge murderous fees to help people with their "Big Data" Cassandra installations, only to find out after weeks of wading through a management quagmire that the data in question can be stored in a few KB text file.
dullgiulio 5 hrs
Incidentally, Cassandra is called like that because she kills the /Oracle/...
unixhero 2 hrs
Devious! I love it.
mgkimsal 6 hrs
"Big Data" doesn't mean "makes Excel slow down" or "needs to scroll in Excel" :) If you can fit it on a thumbdrive you can buy from a Walmart, it's probably not 'big data'.
teddyuk 5 hrs
This really is true, I worked on a project where we were meant to be getting hourly files into a data lake, the files so small we couldn't reach the recommended size of 256mb per file (compressed parquet in azure adls) - the files were like 1 mb each - a years worth of data was tiny and the processing overhead ridiculous
jjoonathan 5 hrs
If your workflows don't bog down your servers, add big data technologies until they do!
walshemj 5 hrs
I think if you cant fit a single data set on the biggest commonly used hard drive is another good metric.
allenskd 5 hrs
It's pretty much what's happening on my assigned project. It's a legacy app created in the 90s... most of the time spent is just things that takes 1-3 days but due to the constant tweaks and re-tweaks it can take months. In a personal sense it doesn't affect me. I do the work they require me to do and get paid for it. Professionally and personally, I'm a huge mess because I'm frustrated on how bad is the decisionmaking. I feel I'm just wasting, and even though I'm paid for it it just doesn't feel like I'm doing anything with my career. Sigh.
diggan 5 hrs
In a personal sense it doesn't affect me
I'm a huge mess
I feel I'm just wasting
doesn't feel like I'm doing anything with my career
Sounds like it does affect you in every sense.
You should probably try to adjust that, before you burnout not just for that specific job but your carrer in general
allenskd 5 hrs
I'm burnout and have been questioning myself after 2 years servicing clients in the company I'm in if I'm good enough for other roles (using as example) promoted in HackerNews, or whatever job portal.
When I spend so much time idling by and letting that frustration build up... I just start questioning if I'll be able to do other roles and not fail the team or whatever company I'll be working for because of how dormant I am.
It's not like I knew a lot. I don't consider myself to be super talented, just the average guy trying to make it out there but yea... I need to look into moving on.
Lewton 2 hrs
I was in the same situation as you at my previous job, feeling like I wasn’t learning anything because I was working on a legacy system where every design and business decision made was pure insanity
After five years at this place I finally got my shit together and applied for a job
I spent the job interview asking pointed questions about their infrastructure and how they ran their business and then I contrasted their way of doing things with my old job and explained why their way was so much better
Turns out I was learning! And learning how NOT to do things carries some value
beauzero 4 hrs
My advice is to interview a couple times (with companies you don't mind missing out on), find out what you are missing and work on side projects that interest you. Then interview again about 6 months later. There is nothing like interviews to set your mind straight. Competition and hard questions seem to energize my "survival" instinct.
...doing something hard and outside of your comfort zone I guess is what I am recommending.
EForEndeavour 4 hrs
Invest time into thinking about and listing specific things you've learned (technical, but also organizational, managerial, etc.) from maintaining this horrible legacy system.
This list will show you that it hasn't been a complete waste of your time, and it will show future employers that you're thoughtful, observant, respectful of your own time, and healthily critical.
arethuza 9 hrs
My estimate would be that about 70% of all IT/software projects on the planet are like that.
Edit: Clearly I am in an optimistic mood this morning.
retSava 3 hrs
Sometimes the desired result is not known ahead, at project start, and twisting and turning is part of the process of (hopefully) ending up with something that people are happy with. It's just part of human nature and needs to be embraced. You just ensure you are paid for it.
wool_gather 53 mins
This is the optimistic take. :) But there's a difference between
exploring the design space and iterating until you end up with a product that makes the customer happy
and
endlessly reworking decisions every time the next "stakeholder" in the customer's org sees a part of the bikeshed that they have an opinion on
One is a skill-engaging and -enhancing professional project. The other is the road to burnout.
csomar 7 hrs
This has been my experience and it might be sane. The 90% went on project/requirements discovery. Remember that you are doing this through several people, so it's multi-dimensional and once you leave 2/3 dimensions things start to get really complex.
itronitron 7 hrs
I think most of the impediments are intentionally created to hinder projects so that nothing looks to easy or successful. This may help explain why some PMs or product owners inflate the product features when internally advertising the effort, that way if other people throw up roadblocks they are less likely to impact a core feature.
mdpopescu 7 hrs
I suspect something similar. I had a project which had a team of developers for six months; we didn't do anything the first four months (I spent a lot of time on HN during that time!). After those four months, we discovered that during the last month, being December, we were not supposed to release anything (as it might endanger the end-of-year runs). We did the entire thing in two weeks and then deployed it in the remaining two (deploying was a nightmare).
At some point, we discovered that the team lead wanted to be promoted to manager so he needed a reasonably-complex-but-actually-simple project as a "win".
joncrane 2 hrs
The consolation prize is that you're paid by the hour.
twervle 10 hrs
if people listened to me at the start of the project.
The dream of all software developers.
arethuza 8 hrs
That assumes that the problem is best solved by developing new software - which quite frequently isn't the case!
clarry 6 hrs
That assumes software developers think the problem is best solved by developing new software - which quite frequently isn't the case!
Oh how I wish we could stop reinventing this same stupid wheel badly. And change the "wants" framed as requirements into something more reasonable, so that we could get away developing less bumpy wheels, perhaps even use one off the shelf.
jimmaswell 2 hrs
Oh how I wish we could stop reinventing this same stupid wheel badly. And change the "wants" framed as requirements into something more reasonable, so that we could get away developing less bumpy wheels, perhaps even use one off the shelf.
We'd be out of many jobs if this happened.
clarry 2 hrs
We'd be out of many jobs if people started breaking windows.
Or maybe that time & money could be spent on something else, it's not like we're running out of things to do.
arethuza 5 hrs
Well, in my experience a lot of developers do generally see the world in terms of opportunities to develop new software.
Edit: I don't think is a bad thing and I am prone to it myself !
reallydontask 5 hrs
I am very much in agreement with you.
At my previous place, after several times where the wheel was re-invented I asked one of my senior guys what did he think he got paid for.
Perhaps unsurprisingly the answer was to design features, write code, review code and advise support. Whether any of this delivered any value to the company was, seemingly neither here nor there and he'd held my position before I joined the company, so it's not like he never had to think about these things or at least he should've thought about those things but the code would testify that he hadn't.
Sadly, this is pretty common
lmm 3 hrs
I do think it's a bad thing. In my experience the best developers are those who view new software as a last resort (or rather a second-last resort, with manual work being the last resort).
tmaly 5 hrs
As he said he was green, I think this really shows that early on, young developers do not always understand the importance of requirements gathering and problem understanding.
Just yesterday, a junior developer from my team came to me about a request to generate some output from historical data. I went back to the business side and determined it was just a simple switch of several columns in the input data to get the results.
My junior developer at first thought it was some monumental problem that was going to require a lot of work.
duxup 2 hrs
Similar story.
I'm a noob when it comes to coding but I worked a technical job with customers for 20 years before changing paths.
I was in a position where I joined a place as the "new old guy" and several new college grads.
One day the president of the company comes to me and asks "You know the questions to ask! Some of our experienced guys don't."
It takes a lot of effort for two people or groups to form an idea and be on the same page, understanding "all" doesn't mean *, thinking of roadblocks before you get there (seeing them coming), softly working around those roadblocks, helping frustrated people, offering alternatives without going off the rails, listening closely to find out what is REALLY important and etc. I think that stuff just comes with experience working with humans.
My own experience makes me think everyone should be required to work some form of technical support for a while ;)
mooreds 3 hrs
Yup. Knowing when to go back and clearly define the requirements is a senior type of behavior.
"We don't have time to think, just do!" is a recipe for disaster.
lmkg 1 hr
As the saying goes, months of development work can save hours of planning.
duxup 2 hrs
They said they wanted everything so the DB displays in a table ... everything.
IggleSniggle 1 hr
Hey works for me, let me just get my web-scrapper going so I can--hey wait a minute!
kingaillas 2 hrs
Great story!
Out of curiosity I wondered about the current state of the Prudential website. So I searched, and found Berkshire Hathaway bought the real estate arm in 2012 and now they are Berkshire Hathaway Home Services.
I did a local search on the website, received pictures and basic information (price) for each house... and for each one it lists the same toll-free number as a contact.
So the site he built basically works the same way!
vfc1 9 hrs
My shittiest project was a hostile takeover from another development team.
In the interview, the manager told me a bunch of BS that turned out to be completely false: that it was a new project, that lots of new development was expected, that there where performance challenges to be tackled.
When I got there, I found out on day one that the goal of the project was to take over the code base from an existing development team, with which the customer had lost trust because among other things they refused to use their new shitty trouble ticket system (which was awful), and instead insisted in using JIRA.
Also, they had a server running in Tomcat that they didn't want to migrate to Websphere.
Turns out that we didn't even have access to the code, until we accidentally found that the SVN repo was listed in an infrastructure powerpoint, and we did have a VPN connection set up.
We were at the taking over consulting firm offices and not at the customer, reverse engineering the existing 7-year-old codebase without any assistance from the development team, which didn't even know that they were getting replaced.
After months of reverse engineering and producing useless documentation so that the client manager could say in some meeting that the system was well documented, we ended moving in and mostly doing production support instead of development.
Our managers were afraid that we broke something, so they did everything to make sure that we didn't spend our time coding.
After a few months, I just asked out because it was not development work and this type of work was actually harming my career and even had my consulting manager actually shout to me on the phone and tell me that he would blacklist me at his company.
Software consulting is some of the shadiest businesses out there, beware.
The amount of lies that gets told to candidates just to get them signed at the dotted line to contracts without exit clauses (which was the case with me), the use of outdated job descriptions, the lack of information that you have about the actual job even if you ask a lot of questions in interviews, you really never know what you are getting into until day one.
Here is a tip from what I have learned: ask a ton of questions about what the job will actually be, if they answer evasively or strangely seem like they want to avoid the questions and move on to other aspects of the interview, that is a huge red flag.
itronitron 7 hrs
Our managers were afraid that we broke something, so they did everything to make sure that we didn't spend our time coding.
that's like hiring football players and not letting them on the field out of fear they'll score for the other team.
please write a book!
vfc1 7 hrs
Yes its insane LOL Managers were non-coders themselves, and they looked at developers with suspicion.
This happens in a lot of projects, where developers are almost treated like children or assembly-line workers.
I realized through small hints and queues over time that the goal was to take over the maintenance of the project and make sure that we could fix things if something broke, but not add any new features.
They even had a management term for what we were doing. They called it KIR - Keep It Running! LOL
teddyuk 5 hrs
yes but happens a lot - if you dont change it, it won't break (expept it will, every time because the reason you don't change it is because it is crap in the first place)
em-bee 7 hrs
could you elaborate on the negative effects on your career? were you a contractor or an employee? and why would someone blacklist you specifically? how was that consulting manager related to the project?
i mean as an employee, if i get put in a hard position, sometimes the only choice is to quit, so, in that case, the CV would have an entry that you would not look back at to happily, but other than getting out as fast as you could why would being stuck in such a situation harm your career?
vfc1 7 hrs
Yes sure, already after a few months doing production support and reverse engineering instead of coding, you start getting questions on interviews about why are you not coding lately anymore.
This was a bad look, because hiring managers want active developers for coding positions. I ended up not even mentioning that the position did not involve much coding on later interviews, I left after 6 months.
You are put in a tough position because you will have an entry of 3 to 6 months on your profile, which is generally a red flag for hiring managers as it's too short.
An entry with a full year or more will not raise any eyebrows, but 3 months will. Also, because you leave against their will, they won't give you references to the next jobs.
I did end up leaving it was a real nightware, and never looked back, but to this day I feel that I was flat out lied to on the interview about the job content.
In other interviews at other places, I was left out critical details, like for example that the team is moving to another city in two months, and you are expected to go with them.
So this why I say, you never know what you are getting into with software consulting, it's a shady business.
With the high turnover rates and the difficulty to find developers, hiring managers are incentivized to embellish otherwise mundane positions in the interview process, leading to unmotivated staff and further turnover.
tomrod 5 hrs
Several 3 months stints are a problem. One, bookended by reasonable work, is a filter. If a company is overly concerned with one, they just want a skill hire, which may or may not be your target.
You can describe the stint in several ways, such as "the strategic direction the consultancy took was away from software and into project management early in the project cycle. My personal strengths lie in..." or some such.
mdpopescu 3 hrs
You are put in a tough position because you will have an entry of 3 to 6 months on your profile, which is generally a red flag for hiring managers as it's too short.
As an employee, probably. As a contractor, I prefer short contracts (1-3 months is short, 6 months is average) with a clear deliverable. If I wanted to just "sit around and do whatever" I'd get employed.
em-bee 1 hr
agree, it's all a matter of how you look at it. in my CV i don't even make a distinction between contracting and employment. i have even been contracting with and was employed by the same company at different times.
RhodesianHunter 7 hrs
Or just avoid consulting. There are plenty of other opportunities in software that AFAICT have better hours and higher pay.
vfc1 7 hrs
Higher pay than consulting its hard, a consulting job pays usually almost twice as much as a permanent job.
I prefer it to permanent, because besides the monetary aspect you can also get into new projects just starting out more often, and that is were you learn more when compared to maintenaince projects.
What type of opportunities would you recommend other than consulting?
zaphar 5 hrs
I believe maintaining software is great way to level up some of the most important parts of software engineering.
You severely limit your experience when you keep yourself from being around for the aftermath of your software 3-5 years later.
tigershark 7 hrs
Contracting is different from consulting. As far as I understand when you are consulting you are a permanent employee of a consulting company that assigns you to various projects. When you are contracting you work for a temporary period of time exclusively for a client until your contract ends or you find better opportunities. The first case is paid double of the permanent to the consulting company, but the employee of the consulting company is lucky if he gets as much as a normal permanent. A contractor on the other hand gets paid much more than a permanent, especially counting the less taxes that he needs to pay. There is a 3rd option when you actually own the consulting company, but then it’s up to you to find clients and if needed additional resources to assign to the various projects, but in that case you may be paid even more than contracting if you have no down time between projects.
barrkel 6 hrs
That's not what I understand those terms to mean.
A contractor is effectively a non-permanent employee: someone you hire for a fixed period because you have irregular work load and you need some extra people temporarily. I say effectively a non-permanent employee, but it's really skirting the edge here: if the relationship is too much like an employee, then the contractor is an employee for tax purposes.
A consultant is someone you hire for their expertise. They're a specialist; they tell you what you should be doing, rather than doing work you specify.
https://www.itworld.com/article/2801854/know-the-difference-...
https://www.crunch.co.uk/knowledge/tax/consultant-contractor...
IT contractors are also usually employed by contracting companies that take care of accounting and other overheads, and if they do things like marketing and referral, they'll eat a significant chunk of the fees too. I don't think there's a significant difference in organizational structure between contractors and consultants in this way. It's mostly that consultants address the problem at a bigger distance, and are more likely to be drawing up the plan, rather than working on the execution.
tigershark 6 hrs
ok, it makes sense, but then the consultant is kind of the 3rd option in my previous post but his job is to advise rather than actually do all the work, right?
RhodesianHunter 6 hrs
Contractors have to pay more in taxes, not less, since they owe both sides of social security and Medicare.
tigershark 6 hrs
I guess it depends from the country and the type of contractor. In UK, with a limited company, you pay less taxes (at least until next April). If you are under an umbrella company you will pay more taxes because you’ll be paying all the taxes of a normal employee plus the taxes of the employer. No idea if it is different in US and other countries honestly...
yardstick 5 hrs
What happens next April?
tigershark 5 hrs
It’s a very good question, and a long story. As far as I know still no one has a certain answer. The back story is that in April 2017, if I remember correctly, all the contractors that worked for public companies were forced to be under the IR35 rule. This rule, in short, tells that the contractors are equiparable to permanent employees. So they had to pay taxes as permanent employees, without the perks, like paid holidays, sick days and so on. This caused a quite massive loss of public contractors, understandably. From April next year they are implementing the same schema in the private sector, with the difference that it will be up to the employer to declare who is inside IR35 and who is not. The mainstream theory is that employers will start putting everyone under IR35 to avoid problems with HMRC. Even if this won’t be the case at the beginning, after the first couple of high visibility cases in which hmrc punishes the employers for some wrong IR35 classification, all the others would want to avoid the risk and headaches and will classify everyone inside IR35. We’ll see next year how it turns out, but I’m not very optimistic. Luckily for now I’m shielded, but I’m paying an eye watering amount of taxes...
mattkevan 6 hrs
After working in a web agency for years, my number 1 red flag that the project is going to go badly is the quality of their current website they’re hiring you to fix/replace.
If it’s solid but just a bit old or needs more features, you’re fine. But, if it’s crap, look out.
The quality or lack of is never down to the the people who built it (unless it was by the MD’s nephew or something), especially if the client blames them for it.
It just shows they can’t run a project properly and whatever you end up with will be just a slightly newer pile of crap. And they’ll slag you off to the next lot.
Number two red flag is if they say at any point “You tell us, you’re the experts!” This can be translated to, “We don’t know what we want but we’re going to reject whatever you say anyway.”
mdpopescu 3 hrs
Number two red flag is if they say at any point “You tell us, you’re the experts!” This can be translated to, “We don’t know what we want but we’re going to reject whatever you say anyway.”
I disagree with this being a red flag. That's exactly why I hired someone to build me a small website. It's not because I don't know HTML / CSS / JS; it's because I'm bad at (visual) design. I wanted someone who knows what they're doing to use their expertise and give me a good product.
mattkevan 1 hr
That’s great, you know to hire an expert and let them get on with it.
The problems start when the client either can’t or won’t explain what they want, then gets upset that what you produce doesn’t match what’s in their heads. At that point they start trying to undo every decision and things go south rapidly.
yingw787 1 hr
Ahahaha...
One company I worked for had a great website. One of my coworkers worked on it as his baby and took great care of it. Rest of the software stack was a dumpster fire.
One other coworker came on board because they thought "no bad company would ever have a bad website". The guy who hired him left a week after he joined. One developer left every week for four weeks afterwards.
Website quality is a weak signal; I'd say if a website didn't have any errors or warnings in $BROWSER DevTools, or made a mention of not pasting JavaScript here or having an explicit "oh hey you're a developer we're hiring", then that's good. Otherwise keep asking questions.
otabdeveloper1 9 hrs
Prudential Real Estate is a franchise operation. Prudential does not actually broker any real estate. Instead, a local franchisee pays a fee for the use of the name and logo and other services.
I don't know how contracting works, but for corporate project the rule is always "follow the money", then once you figure out the money flow, only then do the requirement gathering bit.
Doing it in the opposite order will result in tears.
beat 4 hrs
As an aside, "Tell me about a project that failed" is one of my favorite interview questions to ask. Failure is endemic in our industry. A candidate that only tells you about success isn't telling you their whole story.
And a candidate who talks about failures in terms of what everyone else did wrong, but never acknowledges any failures or learning experiences of their own, is telling you something important, too... they're telling you that either they never learn, or they don't tell you the whole story.
jlarocco 31 mins
Maybe I've been around too long, but this doesn't seem too bad. The guy made a lot of mistakes (flat fee, not talking to users, etc.) and then suffered the consequences.
As far as the shifting requirements, management nitpicking, "dirty" imported data, and all of that, it sounds like any software project at any medium or large company. It describes a lot of projects at smaller companies, too, for that matter.
silveroriole 5 hrs
The only thing that’s ever worked for me to avoid these scenarios is getting all the relevant stakeholders physically in a room for a couple days and drawing mockups, looking at their systems, learning the domain lingo, running reports over their data, etc as we go. Otherwise the domain knowledge for a proper solution just isn’t there, even for a ‘simple’ project.
Unfortunately I also hated every minute of doing this and have switched to a back-end job where I never have to interact with a customer again!
pbhjpbhj 3 hrs
There's a lot wrong with this whole thing but the end solution is the wrong way around too - you don't require the client to then take a further step, you get their contact details and then reduce the friction by calling them.
The solution should surely be "enter your phone number and zip code and we'll contact you". Then the central referral agency contact the person immediately, to keep the momentum & check the person's details, reward them for their effort in finding the company, and arrange for the next step -- ideally an at home meeting with the particular agent you booked them with.
Just "right, now call this number" is a bit daft, isn't it?!
dvh 10 hrs
If he was paid by the hour it would be typical, perfectly reasonable contractor project.
erdo 6 hrs
Or if you really want to play the fixed price game, better add a large buffer which you may keep should the project miraculously complete on time. You transfer the risk from the client by doing fixed price work and risk is expensive.
And of course, every client change, goes through a process that evaluates it for additional cost that gets added to the bill. I think this change process is a considerable money earner for consultancies.
But yeah, personally I always just charge a day rate.
twervle 10 hrs
Consulting companies know this and they NEVER charge fixed price.
sdoering 3 hrs
I beg to differ. Working at an consultancy and we had fixed price projects for large clients. We just had to plan a risk buffer into the price.
But I can also tell from experience that fixed price, more often than not, doesn't work out so well.
juskrey 8 hrs
I can say, as a seasoned web apps outsourcing contractor, there are two sides of the medal.
The bright side: clients usually come to me with just an idea, plan or sketches, almost all of my projects were built from the ground up, I totally technically owned them. This is a delight for any coder (and I code a lot, not just manage the team).
The dark side: many startups and green business ventures fail, and the failure rate is around 80%, even larger in the longer run. And I do the apps from the ground up, nurture them.. but sometimes I feel myself a gravedigger.. out of any 10 projects maybe 2 or three are still there after a couple of years.
DonHopkins 11 hrs
At least he didn't have to install Solaris on Sun executive's workstations.
http://www.art.net/~hopkins/Don/unix-haters/slowlaris/worst-...
skrebbel 9 hrs
I feel like I'm missing something in that article. Probably some historical context. Is it really about execs at Sun pranking each other by installing Sun's own flagships OS on each others' computers? Isn't that like "pranking" Satya Nadella by making him use Windows 10?
avar 7 hrs
Windows is meant for desktop use by managers, Solaris was never realistically meant for that sort of use-case.
So it's a bit more like replacing the BMW company car some VP at Caterpillar drives around with one of the 400 ton trucks Caterpillar itself makes. Yes it also has wheels, yes it's also a vehicle, but no, you can't really use it as a company car.
bdsa 8 hrs
"On September 4, 1991, Sun announced that it would replace its existing BSD-derived Unix, SunOS 4, with one based on SVR4. This was identified internally as SunOS 5, but a new marketing name was introduced at the same time: Solaris 2."
I guess the execs didn't have a high opinion of their new product.
DonHopkins 8 hrs
The Day SunOS Died
"Bye, bye, SunOS 4.1.3!
ATT System V has replaced BSD.
You can cling to the standards of the industry
But only if you pay the right fee --
Only if you pay the right fee . . ."
http://www.poppyfields.net/filks/00070.html
For context, the guy who wrote "The Worst Job in the World" email was Michael Tiemann, one of "open source's great explainers." ;) Now he's pranking IBM executives by installing RedHat Enterprise Linux on their mainframes.
https://en.wikipedia.org/wiki/Michael_Tiemann
fifticon 7 hrs
More like making him use Windows Millenium.
lokedhs 5 hrs
This seems weird to me. I was working for Sun at the end of the 90's,and everybody was running Solaris on their machines.
If McNealy or Zander was running something else, that would have been the exception.
jmartinpetersen 11 hrs
Thanks for sharing. Good catch at the end. It's easy to forget this as a developer. But usually technically details are just that in the bigger picture - details. They're only important if the bigger picture is somewhat correct.
mathattack 4 hrs
Sounds like the OP fessed up to the problem at the top: despite hating large companies, they signed up to a fixed bid project as an independent contractor. Given how big companies work, that’s recipe for danger.
Scale is very powerful, but it takes a lot of work to get things done. Large companies have a ton of waste, but getting to “this can work for all of us” has a very big impact.
pjc50 5 hrs
"how do we collect the referral fees?"
This is the underlying problem, and the reason why "disruptive" startups can be successful in the first place; making something more beneficial for the consumer in a big organisation can be at the expense of one of the individual units which can prevent it, even if the change would be advantageous for the business as a whole.
AnnoyingSwede 10 hrs
This is something every freelancer have seen. Who ever introduces you to the job rarely knows what the end-product should look like and it really proves the value of creating a minimum viable product, showing it to customer and pivot from that to where you might need to go. It this case the MVP would have been the final product.
vmurthy 5 hrs
Do you think this is why developers need to be made aware of user journeys? In my experience, just spending some time on thinking through the user journeys has done wonders to my understanding of features.
Edit : The article doesn't mention anything about user journeys. Hence the thought :-)
arethuza 5 hrs
In an ideal world yes - but in some situations its just not practical. For example, I once worked on a (large) project for a company I worked for where we were the customer and developers were out-sourced about four levels deep - they weren't even clear as to who the top level customer was let alone what the user journey was.
zandokc09 10 hrs
It's an amusing story, I've seen this countless times as well. I think what finally sunk in for me was that if you're focused on saving money or efficiency on small projects then the upper limit of benefit to the company is less than the budget for the project. Instead if you focus on optimizing for the market, the profits can be unbounded essentially, and any wasted money to get to market is simply part of the learning process.
And if you're the contractor having to run around as the plans change, well just make sure you get paid enough :)
Xylakant 10 hrs
As contractor I like jobs where I can basically recommend “Just don’t build this at all.” For example the young startup that wanted credit card payment and automation for essentially a two digit number of invoices per year for a target market where bank transfer would be much more common. Replaced with an excel sheet. Customer happy. I don’t want to build crap just for the money that’s in building crap. Let me actually add value.
org3432 10 hrs
Yeah same here, what’s strange is you have to explain that to clients too. They don’t get you’re contracting because you like to actually do things and helping them is part of the reward. Otherwise you’d just be an employee.
aitchnyu 7 hrs
Umm... did you earn the kind dof money the pointless project would have gotten you?
lapnitnelav 4 hrs
Probably no but they surely built goodwill with that company and as a result can help them build a good reputation. This is often overlooked but people will remember that.
Or they could just be satisfied with doing the right thing, rather than trying to extract as much money as they could.
perfunctory 1 hr
Everybody who believes that private sector is by definition more efficient than public should take note.
hyper_reality 11 hrs
Fun story containing a valuable lesson for developers thinking about going into consulting, especially for larger companies.
Iv 9 hrs
In the end, something overpriced but usable was delivered. This project was a success. I wish I could say that of all the projects I have seen.
eXpl0it3r 9 hrs
Wish the article would point out in the end, that this is a perfect example of why you have to talk to the "final" customer at the start of a project.
madprops 8 hrs
I've been becoming less cynic about workplace bosses and their decisions. I'm not really talking from raw workplace experience, but from noticing things I've read. I think a boss order comes from a perspective that is probably right. They have an understanding that a developer might not have yet, their instinct could be accurate, maybe most of the time.
JoeAltmaier 4 hrs
Another takeaway: Prudential skimmed fake 'referral fees' for a task that a web page could do just as well. Of course this was in the old protectionist days when the web was new. But what dense, backward thinking went into this final decision to keep the old phone/paper system in the end.
wazoox 2 hrs
My shittiest project was conceiving, developing and deploying WorldCup '98 live TV graphics. I worked 100 hours/week for 4 months, put on 10 kgs, lost one tooth, and got like a 150$ bonus for the whole thing.
I've posted parts of the story as Quora comments, here's one:
A company named Compusport had secured the contract to provide visually impressive graphics with statistics for WC98, but had the hubristic project of developing the graphic stack from scratch — and that was too ambitious, and a few short weeks before the World Cup the guy in charge with this part threw the towel in… Uh oh.
My company stupidly proposed to help Compusport (the fools :D ). At the time I was CG operator on French TV, and the only person in Europe comfortable with a high-end, IRIX character generator program called Antero. So I teamed with a colleague to build a PC GUI in Visual Basic to drive Antero through the network, and that proved … tough :)
There was several technical hurdles: Compusport main selling point was advanced statistics (it was supposed to be fully automated, IA powered ball and players tracking. This didn’t actually work out, but this is another long, painful and interesting story). So we needed to feed the statistics to the TV screen, coming from a central server. Graphics had to be animated (then a world first at this scale), so the CG system had to be remote controlled from the mixing desk to launch animations and effects. Of course on the different sites there were different mixers (Philips, Sony, GVG, Thomson…) working in subtly different ways. We even had to build some custom electronics to interface some of them with our system… An horribly complex network of various hardware and computers using ethernet, ISDN, serial lines and video… a complete nightmare :)
As a “rehearsal”, Compusport has planned to use the French Football Cup finals on May 2, 1998. Oh, by the way he also “sold” the graphic design for this event. With noone in sight to actually do it, you know, like a graphic artist, and no budget either.
So here how the typical April day was: my colleague Eric was building the GUI that remotely controlled Antero, communicated with the video mixer (so that the FX operator could control Antero animations from the main mixing desk) and the statistics server (to grab game data to feed to Antero) from 8 A.M. to 10 P.M. or later. Way later. I helped him on the Antero API (“to display that page send this and this and then wait for ACK then send this and this”), while during the day working with Marc Tatou to set up the graphics and the animations : “make the red card come forward than flip. A bit faster. A bit closer. That’s it”. Of course there was no GUI to program the animations, I had to write scripts with coordinates and vectors in some weird domain-specific language (apparently similar to the one used on some Ampex digital effect hardware) and proceed by trial and error (that grows your beard).
The rest of the day (and night) was spent building the graphic charter for the French Cup finals myself — I became very proficient in Photoshop quickly…
Finally on May 1st, at 4 A.M., I was done with the graphics, I tapped Eric’s shoulder “look, I’m done!”. No response. I turned to him. He was sleeping soundly, his forehead firmly stuck on his keyboard. We had lost him. Burnt out without recourse. Fallen in combat.
Obviously the GUI wasn’t ready for prime time on national TV. The girl who was supposed to be in charge of CG graphics during the match bailed out in terror (understandably). So without having any sleep for the past 72 hours, I had to manage it during the match, the old way (without any automation whatsoever) which was quite tricky as Antero missed a critical feature, which is the timer (it could only display the system time). I had to write a quick perl script to manage the timer during the match… by resetting the clock at the referee’s whistle and switching the display from a static 00:00 page to the rolling counter. Would have been actually easier to use a good old Chyron Max! but hey, that’s how it went.
After that, we had to find someone else to develop the remote control program.
To be followed…
barking 26 mins
This is a fantastic story, I remember world cup '98 very well, did you get a chance to enjoy France's victory at all?
raheemm 3 hrs
I love reading stories like these. They are insightful and funny.
lostmymind66 3 hrs
I decided to quit my job and travel around Asia about a decade ago and didn't want to teach English, so I worked as a remote software contractor instead.
The project was for a person that was running a side-company while working remotely as a project manager for a Fortune 100 company.
The development team was from various parts of India, Guatemala, and Mexico..and I was the only one that spoke English fluently (The project manager was from Guatemala and translated/managed all of the developers from Mexico..they didn't speak any English). I only got the position because I cut my rate in half, as my cost of living was really low, and I didn't want to have a project that was too involved/stressful.
Some highlights:
The company owner was obsessed with the Scrum process, most likely because this is what she used at her main job. We would have 3 hours of meetings almost every day. On Fridays, we would have an extra hour, where we would be required to tell fun stories or jokes. Since we were all from different countries and most didn't even speak the same language, it was just...awkward.
The interview process was a written English test (I had to take one too). The manager wasn't really that experienced and would give repo access immediately. The result was chaos. We spent an entire month with a broken repo because someone was overwriting the master branch constantly. I was paid during this time to just keep checking in changes from one particular bug fix, which would be working when I was finished with everyone's changes..and then the next day, the master branch would be overwritten.
Turnover was high. I was there for a year and we went through over 50 developers. We had one guy come into our meeting room after he was hired, keep interrupting us, and then eventually told us to fuck off. I think at some point, I stayed because I wanted to see where the train wreck was going and simply because I didn't feel like finding another gig.
The project was a way that made filling out government forms easier. There would be major form updates on a monthly basis, which required lots of code changes. The code base was originally written by an outsourced team, which was horrible. There were two, parallel versions running: original and beta. We were all working on the beta, which was supposed to be the better version. However, it was a complete mess of spaghetti code. I found code, written by the current project manager, where he had copy and pasted examples he found online and left the comments in explaining that it was sample code.
When I received a new task to be completed, it was very difficult to figure out what needed to be done. Bug fixes weren't difficult, but most feature requests were tickets from months or even years earlier and some of the requests weren't even relevant anymore. I would call the boss, to try to get clarity, and she had this way of using corporate speak and talking in circles to say lots of words, but never get the information that I need. When I did, it was almost always wrong. I resorted to just completing the task wrong (which I hated) and I would have to correct it later.
We all had to have our web cams on during the meetings. When the boss shared her screen. Every...single...time, she would forget that she had personal emails on the screen..and we would get to see her sexually suggestive emails she was sending to her boyfriend that day. One time I saw everyone's pay in a spreadsheet. Most developers on the team were getting paid $5/hour or less.
We were expected to work all major US holidays and weekends (I just flat out refused to work on any weekend). We had a meeting on July 4th (since I was in Asia, I this didn't really matter to me) one time and she was in the midst of the aftermath of a party. She looked sloppy and there were people passed out on the floor in the background.
When I finally flew back home to the US, she called me up one day and told me that I was too expensive and she could hire 3 people from India for what it costs to pay me.
IloveHN84 11 hrs
This is the typical case where starting small and simple helps you
1) save significant amount of time ahead
2) give your customer time to identify what they really want
3) help you iterate quickly on newer versions. If something doesn't work, it's easy to throw stuff away
jmartinpetersen 8 hrs
It's absolutely true, and while he could have made a mockup showing how it would look for someone with a zip code in eg. Dallas, getting through the bureaucratic hoops to actually get feed back from those who eventually shot it down ... that's just really hard, most places. "We can't show this to customers/users/management, it's not completely done!"
It's a process problem and you can't solve it bottom-up.
You either get used to it and work to the specs, knowing they will change a lot, or you try to get closer to whoever makes the decisions. More often than not, that leads you to another company working on a different problem ...
Gibbon1 9 hrs
All good advice.
Old army observation. No Battle Plan Survives First Contact With The Enemy. Thus the sooner you get that over with the better.
shezi 8 hrs
As far as I recall, that's actually a quote: „Kein Plan überlebt die erste Feindberührung.„ by General Moltke. Your translation is exact.
Just wanted to add a source: https://en.wikipedia.org/wiki/Helmuth_von_Moltke_the_Elder
yesbabyyes 2 hrs
It's also said, about Moltke the Elder, that he only ever laughed twice in his life. The first time was when his mother-in-law passed away, the other time, when he saw Sweden's Vaxholm fortress.
https://en.wikipedia.org/wiki/Vaxholm_Fortress
markdown 9 hrs
No Battle Plan Survives First Contact With The Enemy
Mike Tyson said it better: https://i.imgur.com/Gy9TWiq.jpg
logfromblammo 2 hrs
They could have a contact form with something along the lines of "click here to allow this agent to contact you", and then the affiliates pay for the leads.
They were so worried about getting paid, they forgot to invent a new way to get paid.
itronitron 8 hrs
this is just a typical application development story
User23 8 hrs
This reads like Conway’s Law, a novel. I love it.
draw_down 10 hrs
That is pretty awful. But you know, and maybe this is just me being too fatalistic due to what’s happening in my own professional life, but most of what we do is a waste of time in some sense.
Just shovel the shit, get paid, and move on. They want it changed? great, change it. They want a form that does something stupid, fine, build it. A lot of people spend their work day ringing up plastic crap that people don’t really need, or whatever. Which is to say it could be worse.
Of course part of what sucks about this story is that the author failed to do the “get paid” part correctly, but I’m speaking generally. I just can’t get too attached to outcomes anymore.
RhodesianHunter 7 hrs
This is depressing to read. It's still a very in demand line of work. If your day to day is that miserable try finding some place that isn't.
barking 13 mins
I can empathise with his point of view. Sometimes all going the extra mile gets you is a shrug of the shoulders or worse, grief.
If tv didn't exist, people would be more impressed with you for inventing blurry 405 line b&w than high definition colour.
The latter makes it look easy, the former gives them some inkling that it's a technically difficult task.
They'll be more grateful and impressed as a consequence.
labster 10 hrs
That was quite the shaggy dog project. I'd say more, but it would spoil the disappointing ending.
TheRealDunkirk 4 hrs
Just a niggle, but "senior web engineer"... in 1995? Uh... given that Netscape Navigator was released in DECEMBER of 1994, can any of us say we were a "senior" "web" ANYTHING in 1995? Sure, I was doing Usenet back on Unix machines in the late 80's in college, but that's not "web." And in 1994, I was dual booting Win3.11 (with Trumpet winsock) and Slackware, and getting on the internet with a free SLIP account, but I was doing Usenet, IRC, FTP, and gopher. Come on, now. "Pretty new" doesn't even begin to describe it. Am I missing something here?
logfromblammo 1 hr
Senior, Web Engineer
Which is to say making HTML web pages during my last year of high school. Just ignore the comma.
rb808 4 hrs
Wow I searched the comments for agile and no hits. This is basic modern project management - get something in front of the customers and users as soon as possible and iterate from there.
xondono 3 hrs
Yes, because that never goes wrong...
Maybe it’s because I’m a hardware guy, but if anything, agile has normalized a lot of bad practices (like developing before getting any specs) that can only be made to work in software development.
rb808 1 hr
Perhaps you're right, but the article here says that is why spec's often dont work. The guy followed the specs, but the it wasn't what the customers wanted.