> 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.
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.
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.
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.
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.
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.
"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.
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 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.
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.
Wow. I hope everything you read is written by a dyed-in-the-wool weapons-grade programmer, otherwise you might accidentally read a perspective on a subject unique from your own.
[+] [-] RyanZAG|10 years ago|reply
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.
[+] [-] pjc50|10 years ago|reply
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.
[+] [-] RankingMember|10 years ago|reply
[+] [-] tsewlliw|10 years ago|reply
[+] [-] Swizec|10 years ago|reply
Only people who like managing other people would be thrilled. Those who do not want to manage, would not be thrilled.
[+] [-] brandon272|10 years ago|reply
[+] [-] jacquesm|10 years ago|reply
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.
[+] [-] vinceguidry|10 years ago|reply
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.
[+] [-] tahssa|10 years ago|reply
My math would be:
Your conclusion seems to only account for completion time and complexity.[+] [-] pacap|10 years ago|reply
Anyway, it's strange to hear authoritative statements about programmers from someone who says "Ever since building my first VBA script in 2012"
[+] [-] jschwartzi|10 years ago|reply
[+] [-] Practicality|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] pjc50|10 years ago|reply
[+] [-] sgt101|10 years ago|reply
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.
[+] [-] zebra|10 years ago|reply
[+] [-] tahssa|10 years ago|reply
[+] [-] onetimePete|10 years ago|reply
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.
[+] [-] collyw|10 years ago|reply
[+] [-] kpil|10 years ago|reply
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?
[+] [-] skyhatch1|10 years ago|reply
But now it seems that we've automated pretty much everything we could, so where to now for the technically minded lazy opportunist?
[+] [-] hibikir|10 years ago|reply
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.
[+] [-] toyg|10 years ago|reply
[deleted]
[+] [-] matthewmacleod|10 years ago|reply
[+] [-] RankingMember|10 years ago|reply
[+] [-] saeeda|10 years ago|reply