If You Build It, They Will Complain | Hacker News Reader

If You Build It, They Will Complain

techvibes.com

89 pointsohjeez38 comments

> Just like the IT departments at large companies, I had created a scenario where I was building internal tools that I wasn't prepared to support and service. The excitement clouded my foresight - and I didn’t consider that each new project would require regular maintenance and ongoing support. I would get asked to add functionality or work on bug fixes, which amounted to several hours of additional work each week. Worse yet, I was on the hook when something stopped working at the worst possible moment.

Woah, he actually writes this off as a bad thing. The only real issue here is that he just created himself a new essential department with himself as the head. Most people would be thrilled - he needs to go approach executive leadership with a simple report on how much he is helping the company and how he needs to hire on additional help. It doesn't really matter that there are possible 3rd party solutions that would work - his solutions are already working and creating obvious value.

This is the opposite of a bad thing - he's probably just created himself a new position and massive raise. I think people talk a lot about all sorts of things missing from CS education, but clearly the best thing a school could do is shove in a bunch of business classes into the CS curriculum to prevent people thinking this is somehow a bad thing.

he's probably just created himself a new position and massive raise

This is not how the real business world works. It's just as likely to get a negative performance review for insubordination, not following procedure, and neglecting assigned duties.

It's a gamble, but one that makes a lot of sense, in a very selfish way: Building a career in one place without trying to take shots upwards is not good: Programmers get more pay by changing jobs, not by being very patient and hoping they'll get noticed eventually. So once you are in a place that isn't a tiny startup (which is in itself a risk), you should take risks for big internal payoffs. If those risks pay out, great. If they don't, then just go somewhere else and try again.

Few things are sadder to me than seeing to talent that is mildly disgruntled, being a key part of their organization, underpaid, not taking risks, just hoping that someone would notice them and pay them appropriately: Providing value without immediate recognition is just asking people to find ways to make you provide more value without reward, as you've already proven that you are too afraid to demand fair pay. I've worked with people that had spent 10 years at a company, working on my team, as pillars of the company, getting paid 60k/yr, sitting next to a contractor billing 125/hr

> Building a career in one place without trying to take shots upwards is not good: Programmers get more pay by changing jobs, not by being very patient and hoping they'll get noticed eventually. So once you are in a place that isn't a tiny startup (which is in itself a risk), you should take risks for big internal payoffs. If those risks pay out, great. If they don't, then just go somewhere else and try again.

> I've worked with people that had spent 10 years at a company, working on my team, as pillars of the company, getting paid 60k/yr, sitting next to a contractor billing 125/hr

The lesson isn't to take big internal risks. The lesson is to engineer your finances to allow you to weather the volatility of being a contractor, and then be the contractor.

Everyone shits on the idea of the contractor, when they're doing exactly what they're incentivized to do: maximize the value they extract in the shortest period of time possible, while providing value to the organization they're working for.

Screw your equity, your business culture/hierarchy, and paying your dues (colloquially known as "F*ck you, pay me").

True. But the day I find myself in a company where that's the case. I'll quit. There has to be room for personal inspiration and activities and management has to know that they are not always right and acknowledge when personal initiative (even if it goes counter to their plan) is doing the right thing. If my boss couldn't accept me ignoring him once in a while and just doing my own thing because it makes sense, I'd be looking for a new one..

I wonder how those people would react once he decided to leave the company.

I think the best path to get that department would be to make everybody aware of the situation, without asking anything, and then finding another job somewhere.

But I've never tried something like that, nor do I think I'll ever try, for several reasons.

I interpreted his comment here as being more about suddenly finding yourself in a position you don't want. If you're not trying to create a new "essential department with [yourself] as the head", you certainly don't want to wake up one day and realize you've put yourself in that position. I posit that most people would not "be thrilled" with a sudden increase in job responsibilities that they a. don't necessarily want and b. will have to jockey around to get paid for.

One likely motivator for writing the tooling in the first place was an attempt to automate away manual tasks, the point of which would be to never think about these topics / problems again. In that light, the idea of being anointed "head of stuff I don't ever want to think about" is likely a reason to find a new job. Some people like to do work that interests them, not manage other people doing work that bores them.

> The only real issue here is that he just created himself a new essential department with himself as the head. Most people would be thrilled

Only people who like managing other people would be thrilled. Those who do not want to manage, would not be thrilled.

Management isn't exactly going to be thrilled when you inform them that you've created a big new cost center for them and they need to hire new people to help you out on internal tools that were supposed to result in automation and lower costs.

If you write it they will complain too.

The article isn't so much about end-users who will complain as much as it is about properly designed software systems as much as it is about in-house and ad-hoc created solutions that are not much more than cobbled together glue.

> Considering that it can take a SaaS company several years just to build an MVP

That's a pretty bad MVP then. Usually it takes a lot shorter than that, even for a fairly complex MVP.

And why limit the comparison to SAAS, there are pretty good reasons why companies may decide not to hop on the SAAS bandwagon that have nothing to do with not-invented-here, it may simply be that they are concerned with the privacy of their users, with the degree of integration that they can provide and with the dependency on an outside party for a (possibly) critical part of their business. They also may not like to leak information that is sensitive to the company or the end-users to third parties only covered by an SLA and not much insight into the design parameters and the degree of care for detail.

A better comparison would be between a piece of closed source off-the-shelf software or a piece of bespoke software created by outsiders but hosted by the company, preferably one for a fixed price to create and a monthly fee to maintain.

Ad-hoc glue stuff is usually extremely fragile (because any changes in the underlying software will break it), uses all kinds of interfaces intended for humans rather than proper APIs and is hard to maintain because of that.

TL;DR; Stuff I build is fragile, therefore you should use SAAS.

> That's a pretty bad MVP then. Usually it takes a lot shorter than that, even for a fairly complex MVP.

I don't think most SaaS companies follow Lean Startup principles. Most of the ones I've had to integrate with have had horrid infrastructures and extremely brittle interfaces. It's a delight for me to actually have properly-maintained documentation available on the web and not an out of date Word document that I have to go back and forth with one of their engineers to understand. Non-standard format implementations are the norm and not the exception.

The general gist I got is that sales guys pluck mediocre, but hard-working engineers from the corporate ranks and build businesses around them. The whole thing is kept together with long hours and elbow grease when it frequently and inevitably breaks.

In my practice I see both. In the SAAS domain I see companies with successful models and crappy execution (but they still remain afloat and sometimes even win the race) and I see companies that are textbook examples of how one should implement a business and scale it. And everything in between as well for that matter.

> That's a pretty bad MVP then. Usually it takes a lot shorter than that, even for a fairly complex MVP.

My math would be:

  completion-time = complexity-factor / workers

Your conclusion seems to only account for completion time and complexity.

Good article, confusing title. I was expecting something else.

Anyway, it's strange to hear authoritative statements about programmers from someone who says "Ever since building my first VBA script in 2012"

Actually my first professional experience was in fixing bugs in and adding new features to an in-house application written in VBA using Access. It's really bone-headed to dismiss someone based solely on the language they choose for a project, especially if what they're saying otherwise makes sense. There are lots of good developers using all kinds of languages, and they all get stuff done.

I'd guess that it was more the relatively short amount of time the author has been programming than their choice of language. I skimmed the article and assumed the author had been programming professionally for 10+ years, just from their tone.

exactly, that's what I meant

Agreed. 3 years is quite short. However, this person is a marketing manager so they have a very different perspective on the authority required to be an expert in programming.

Teach a man to fish, and you've got to put up with his fishing complaints for the rest of your life.

"n McKinsey & Company’s 2012 report entitled Delivering large-scale IT projects on time, on budget, and on value, the report describes one example of a large bank that wanted to create a central data warehouse to overcome inconsistencies in their data. In this particular example, the end goal was never properly defined and the IT department embarked on building a solution that never considered the actual business objectives, resulting in ‘huge amounts of unnecessary complexity’ and significant cost overruns. After 18 months of missed deadlines, nearly $10 million in sunk costs, and no working solution, the bank decided to stop the bleeding and cancel the project altogether."

I don't see how the bank could have got a solution to this from a SAAS vendor... they would still have had to pipe the data to the warehouse, build the reports and management scripts and so on - setting up the data store is a task, true, but so is initialising your store on a cloud provider.

The SAAS vendor will be used for its build expertise only. After the build the bank will deploy inner cloud. And the provider will be payed well for the build and for support.

I don't think you are using the same definition of software as a service as me! Salesforce.com is a SaaS vendor, it creates a solution that is shared by many users on a cloud...

This is like phase 1 in the IT cycle. There's a second phase where because nothing gets done due to cost/value conclusions the IT management gets ousted. New management then goes back to letting these things happen in a effort to become more client considerate. It's a decade long cycle that regularly happens.

If you think you build it, it is actually half finished, and left to everyone to finish- who is able to just use git clone on your mind. Cause there is no documentation.

And no- its not snappy to remark upon this after investing a day on fixing your broken code-garbage can, just because its "free" - cause it was not. Time is money, and if you ask people to work for you for free, you are expensive. Solution: Just do not claim with your project to be what you are not. You're software is not free. You're software is not easy to use. You're software is not plug and play in any way. Do not claim that. Say, that it is a bolted together prototype and warn people who don't have experience with this, that they might be in for a investment of weeks. Everyone stays happy.

I thought it was well known that prototypes almost always end up in production.

OK.

I almost stopped reading when I got to "VBA, 2012" and presumably a few more years of work experience before that.

But OK. If you are actually saying: "Hey - it seems to be a bit complex, maybe we should ask a professional before writing our own excel-based maintenance hell for our internal processes." Then I'm with you.

But don't outsource important stuff! m'kay?

I remember a popular unicorn founder (can we just call it that) once referred to himself as "opportunistically lazy". That certainly fits with the technical persona since something within makes us averse to repetitive work.

But now it seems that we've automated pretty much everything we could, so where to now for the technically minded lazy opportunist?

There's many reasons to want to avoid writing custom software, but for those that aren't actively living in it, it's easy to forget the dismal results of buying enterprise software.

People buying it start with the impression that 3rd party software is good: We don't write our own mail program, we don't write our own word processors, so of course we shouldn't write anything a third party offers, they say. But that shows a total misunderstanding of what makes software hard: specifications.

It's not difficult to build an application for a good price when we expect tens of thousands of sales, and it's a task that will occupy mind-space, so we expect users to be motivated to learn whatever idiosyncrasies our application has. But when the application should interact with other applications, or there are relatively few users, it's very hard to build it economically: Most of those 3rd party disasters are in those areas.

For instance, we've had a bunch of very pointy haired people decide that our org needed some kind of REST API + authentication management combo, and went out there to purchase something, because building is bad. But it is exactly the kind of system that will does not work well: It's built for big enterprises, so it is seven figures, with recurring costs. It does not interact well with the specific quirks of how the internal authentication works, so hacks are needed. The UI is not really built for you, or anyone, so it makes the AWS dashboard look like a UX miracle. And then there's the bugs: There's still bugs (A lot of them), but now, instead of your own people fix your bugs, now you have another company dealing with them, and since you already paid them, adding new features is more important than fixing your bugs. So now we are out a bunch of money, everyone that isn't pointy haired hates interacting with the thing, and we've needed a bunch of custom code anyway.

The decision between buy and build is not necessarily easy, but there are a very valuable rule of thumb I love:

If you are going to custom build, and it's not key to your secret sauce, expect to spend a bunch, and build it as an open source project.

Having other companies use whatever you are writing makes quality improve faster, as there's more people to find problems in your specification and your implementation. Sometimes you get people to help you with free labor. Others they don't. But either way, you've lost almost nothing by making your code public.

If you are unwilling to commit to making it open source, because it sounds expensive, then you really were not going to commit to it as custom internal software anyway. It would have ended up as a piece of crap everyone hates. So then go and buy, as you weren't going to get any gains from building it custom anyway.

They will always say something.

Reply on news.ycombinator.com