Its from a different domain, but it gives you a flavour of the headaches you encounter. These systems always look simple from the outside, but once you get inside you find endless reams of interrelated and arbitrary business rules that have accumulated. There is probably no complete specification (unless you count the accumulated legal, regulatory and procedural history of the DVLA), and the old code will have little or no accurate documentation (if you are lucky there will be comments).
Basically this. The people running the show would desperately like to make it simpler, but ultimately it’s left overly complicated due to priorities from past leadership well above our paygrade.
The right solution is always to just rip off the bandaid and do it again by hand in a new language or platform, and to eliminate useless complexity while doing so. Unfortunately no leader would ever do this because the Board and/or Shareholders would crucify them for not outsourcing it to McKinsey first and using the fancy-pants automation tool their report recommended.
There are a few shareholder-friendly patterns to get this done, but it is domain-specific. I’d say it’s more “rip off the bandaid slowly and carefully”.
Eg a common one is to wrap a new no-op new service around the old one, and gradually replace parts of the old one (the “strangler fig pattern”).
This is technically great, but it’s also financially great because you are don’t spending large sums on a big-bang rewrite. You’re spending relatively small sums on a “pay as you go” basis, something board members and shareholders do like.
But of course this depends on how your systems are set up.
Well, that, and any organization that has gotten themselves into this situation tend to have a very strong risk aversion principal. Which means they _can't_ approve something like this organisationally since there is simply too much risk embedded, and someone has to accept that.
This sent me down a rabbit hole remembering the DDoS attacks the skids were coming up with in the 90s. The famous Pepsi & Smurf attacks that would spoof a connection from one server running CHARGEN [1] and send it to another running ECHO [2] and it would just send an endless flood of characters to the victim. It might have been one of, if not, the first distributed denial of service attacks. It's wild to think people would leave all the ports open on their servers that would just spew endless characters and etc. Those were the days when everyone was so open and trusting of other users on the internet.
CORRECTION: This was actually name "Fraggle". [3] Smurf involved ICMP flooding.
I remember seeing these on EFnet IRC in the 90s. Since the code is so ancient, I thought I'd share it. I'm sure these would be useless in modern times, but they're an interesting bit of internet history. It also hilarious to look at the comments and see old IRC handles you recognize. Who remembers napster before he developed the p2p software that made him famous?
The ONT's job is to translate from (typically) Ethernet to the optical fibre, and nothing else. In networking terms its "Level 1"; concerned only with moving bits from one end to the other. Most ISPs will provide an ONT which does that and nothing else, and then a regular router/firewall that plugs in to the ONT via Ethernet.
Your security barrier is the firewall in the router, plus whatever encryption you apply to comms outside it. As long as you get that right your ISP can't see what you are doing apart from the to/from addresses on your packets (which can't be hidden, obviously).
ISPs generally push their own managed router/firewall at you because that way when something isn't working you don't wind up with arguments about who's fault it is, and the ISP can troubleshoot your router. But in my experience they have no problem with you unplugging their device and plugging your own in instead.
I haven't seen an ISP which does the ONT and the router in a single box. Its theoretically possible, but would be a bad idea for several reasons. One is security, as you say. Another is that the fibre can't be extended with more wire, unlike a copper phone line. So the ONT tends to be a small wall-mounted box with an Ethernet jack in it. That way your Wifi access point isn't stuck low down next to your front door or something.
What, I think, you mean to say is "Layer 1" of the OSI model, which is still incorrect. An active device, even when "dumb" is a "Layer 2" (Data Link) device. Ultimately a "bridge" networking device. The device is doing local media conversion which can't be accomplished by physical media interconnects alone. Even if the data link protocol is the same on both sides bridging the media types often requires a conversion. But in the case of ONT it's not going to be Ethernet on the WAN / carrier side. Not sure of the setup here but the PON is usually a very "dumb" last mile as it's often some sort of DWDM driven headend that's splitting out wavelengths for downstream consumption by the PON via the OLT and then broken out to Ethernet on the CPE, which is an ONU in this case.
It is not quite as simple. The ONT also maps services to ports. Take for instance an ONT with 4 ethernet ports and 1 FXO port. The FXO port can be mapped to a SIP service, and each ethernet port can be mapped to a different network service. They can even have multiple tagged VLANs. Multi-port ONT's are often used to deliver services to multiple businesses sharing a premesis, or those that want an equivalent to a leased line in combination with an internet service.
I think I see what they mean. "Misconception" means something where you can point out "no, that's incorrect". But these people have more than just an error in their knowledge, they are fundamentally misconstruing the world and how it works.
I would love to see the part of the study that says this and how they controlled for various factors. Are rhe baselines just other studies built on surveys? Self perception is terribly inaccurate much of the time, and we all know people put more emphasis on the things they don't have than the ones they already do.
* The time you spend managing and supervising, including desk-checking the stuff they send out, because it goes out under your name and you are only as good as your last job.
* IT costs, and office space if they aren't working from home.
* Liability insurance in case they screw up. (Not certain about this: maybe you just trust that your company is a sufficient legal firewall because its only asset is you).
I remember back around 1990 hearing that for my big company employer putting a coder in a seat in front of a computer cost roughly twice their salary. That's still true today.
> The time you spend managing and supervising, including desk-checking the stuff they send out, because it goes out under your name and you are only as good as your last job.
The article effectively references this when it starts talking about having to pay for a full-time manager once you have five employees. If you've added only one employee, this is largely a cost that is paid proportional to their billable hours, and you only need to be slightly more diligent than your client, so it's not much of a loss.
> IT costs, and office space if they aren't working from home.
For a small-scale consulting business, usually they're working remote or on-site, so you don't necessarily bear any office space costs. There is, invariably, some IT costs that you bear yourself, but you already have those when you're operating on your own, and the additional cost for your first employee is all but trivial compared to the billables you should be adding.
> Liability insurance in case they screw up. (Not certain about this: maybe you just trust that your company is a sufficient legal firewall because its only asset is you).
More often than not, customers want you to have liability insurance because you don't have a lot of assets they can grab in the event sue you, so the better your legal firewall, the more likely you'll have to pay for liability insurance. Still, it's a 1% cost, so not a big factor.
> I remember back around 1990 hearing that for my big company employer putting a coder in a seat in front of a computer cost roughly twice their salary. That's still true today.
That's what the article says. It actually argues that with consulting businesses, it's more like triple their salary.
And even if they do pay, larger companies often insist on net-60 or even net-90...so you have to wait potentially months after delivering work to get paid. For a small or new shop that alone can put you on the ropes, especially since the companies most likely to do this are likely to be large enough and pay well enough to be the bulk of your inflow.
There are solutions for literally all these problems, you can find banking relationships where they’ll lend on your outstanding invoices, you pass on interest to the client, and everyone gets paid.
I feel compelled to comment because there are all these people who act like running your own business is some impossible task. it really isn’t. The vast majority of business owners aren’t super geniuses, my 60-year-old mother does it, has no formal education and couldn’t write “hello world” if her life depended on it.
The reality is that owning a business is effectively monetizing your creditworthiness (not unlike being a landlord), which is a pretty easy way to make a living, assuming you start out with a decent supply of capital/creditworthiness.
I don't think the problem for tech people is in thinking it's too hard.
I think it's trading working on what they like vs doing admin / sales / marketing.
That said, I wish everybody were a contractor and employees wouldn't exist.
(Good) Contractors are accountable exactly to what they are paid for (no more and no less).
Employees are accountable to drinking coffee and it's a damn pain working around them to try to get something done.
The only exception is people with equities working in startups and dreaming big.
> I think it's trading working on what they like vs doing admin / sales / marketing.
That's certainly one of many good reasons not to run your own consulting business. That said, it's entirely possible to hire/outsource support to do much, if not all, of the admin/sales/marketing work.
> (Good) Contractors are accountable exactly to what they are paid for (no more and no less). Employees are accountable to drinking coffee and it's a damn pain working around them to try to get something done.
In my experience, productivity tends to depend more on the "good", than on the contractor/employee dimension, and a non-trivial part of the "good" stems from how well they are being managed by the business... which yeah, a huge part of being good at managing either contractors or employees is about accountability. Sometimes you get better employees or contractors than you deserve, and that can imbue the contractor/employee characteristic with more causal significance than it deserves, but by and large, you don't.
The article, and much of the commentary here, said exactly the opposite.
It's not that it's too hard; it's consulting businesses aren't very profitable, don't scale well past 1 person, and if you scale, fill the owner's life with way less enjoyable work.
That's pretty simple to manage though. If you're going with say... 2/10 net 60, you charge them at a 3% higher rate. Clients might perceive this as charging interest, which it is, and they'll be perfectly happy with it. If you have cash flow issues, you borrow to cover the float —net 60 billables to large companies tend to make you not a credit risk; even with high interest rates of today, you'll come out net ahead.
It’s only 1% of my gross income (before tax) as a freelancer. I’ve never seen or heard of it being exercised in my sector (management consulting / cyber), but to be honest it’s a small price for peace of mind in case things do go pear shaped.
In the case of the Consulting company I worked for before starting my own, they expect you to get the above stuff done above and beyond your 40 hours of billable work.
Definitely not the norm at the places I've worked. I would even bill for some downtime if the customer was blocking me from getting work done and the contract expected me to work full-time as it was preventing me from taking on other work.
No complaints in over 15 years. Just be good. Keep your customer happy and get stuff done on time and on budget and these sort of things just work themselves out. Much of it relies on setting clear expectations and goals up front.
It depends on the nature of the contract. Certainly that is the norm, partly because the IRS tends to like it that way; but I've seen contracts that explicitly paid for dedicated managers, included IT costs and office space, and even ones that covered liability (usually when your a subcontractor and the contractor with the MSA requires liability insurance so they can sue you if things go sideways).
Me too. I tend to hide that stuff in my overhead so that my proposals and clean. I just bill my time, materials straight through. No more complicated than that.
Then I handle it all on the backend, you just need to make sure you are bidding enough time to get it all done. The client doesn't usually want more granularity, then they feel obliged to review it. Just get the work done, charge them what you agreed to charge them, and be jovial as you do it.
> The client doesn't usually want more granularity, then they feel obliged to review it.
It really doesn't make sense for them to review it anyway. As a general rule in the consulting business, if you don't pay for it with expenses or in the rate, you'll pay for it in the billable hours. A successful consultant will necessarily make sure all their costs are covered, with room for profit... and you want the consultants you hire to be successful.
How much maintenance does this take to keep its reflectivity? Does it get colonised by algae? If it needs to be scrubbed with bleach once a year, I can see that being an issue.
Has anyone pointed out that in the UK 999 is the emergency number (like 911 in the US). So "999 Request Denied" sounds like a public safety issue to someone who doesn't speak tech. Make it 998 if you must.
I think if someone is looking at HTTP codes and extrapolating THAT from the response then there are other issues. At that point we might as well worry about people in Atlanta, GA not being able to call their mechanic if there's a 404 page.
I use a Raspberry Pi, cheap USB webcam and https://raspberry-valley.azurewebsites.net/MotionEye-OS/ Motion Eye to watch out for intruding cats coming through the cat flap. Entirely open source, completely under my control, and simple to set up. What's not to like?
> During COVID the government tried skipping those procurement rules in the interests of expediency. The result was a huge corruption scandal.
I don't think that this is the guaranteed outcome for all governments and situations.
In Latvia, the COVID-19 contract tracing application "Apturi Covid" wasn't developed with a bunch of buraucracy beforehand, but as a voluntary community effort between both different orgs and people. As a consequence, it was developed reasonably quickly, actually worked and was helpful (even if the user numbers weren't as great as expected, but that's besides the point): https://lv-m-wikipedia-org.translate.goog/wiki/Apturi_Covid?...
I know this because I was a part of the developer team (the website in particular: https://apturicovid.lv/#en before handing it over to govt. once my participation was concluded) and it was actually encouraging to see how well professionals with a common goal can work together, as opposed to some of the less successful processes I've seen. In particular, our e-health platform was once of those serious government projects with lots of bureaucracy, yet still didn't work after many millions in investments: https://www-lsm-lv.translate.goog/raksts/zinas/zinu-analize/...
(I've mentioned this previously, but the point still stands and the contrast is very apparent)
I don't see why a slightly more streamlined, iterative and goal oriented process couldn't work for commercial software projects, even in the public sector. Of course, if the clients don't know what they want and change their requirements whenever new people come into the office (new management), no particular process is going to save you. Nor will you be successful when people quite frankly don't care about shipping software that works and instead of answering your questions just throw a PDF with 200 pages at you, that doesn't provide the actual answer either.
Nothing specific, but I've seen some big systems from the inside, and I know the kind of thing that leads to failures:
* Back in the 60s they got a big IBM computer to do some stuff. Then later on they needed to do other stuff. The old computer was too expensive and difficult to replace, so they got a new VAX or something to do the new stuff and talk to the old mainframe. Then some PCs got added to do more stuff, and so on. Today the back end consists of many different systems of different ages all talking to each other using different protocols that were designed against different requirements. Newer systems are forever being patched and updated to cope with new requirements, while the code for old requirements lurks waiting to be accidentally reactivated. Each of these systems has its own specialists for care and feeding, but nobody fully understands the whole thing. When something goes down there are not many people who can diagnose the fault and get it back up.
* Government contracts have lots of rules around them to ensure value for money and prevent corruption (see the UK COVID PPE fiasco for what happens when you try to cut these rules out). But the size and complexity make even bidding for a big contract very expensive and complicated, so it tends to be the preserve of a few big companies who chose to specialise in it. Their core competence is winning these contracts, not delivering on them later.
* These rules mean that everything has to be specified in detail up front, so that everybody knows what is supposed to happen. But this makes the whole thing horribly inflexible. As new requirements emerge from the woodwork there is a continuous process of renegotiation.
* The UK civil service is based around the "cult of the gifted amateur". Senior managers are rotated around departments every few years. So the person who kicks off a project is rarely the person who sees it through. Everybody gets to blame someone else for failure.
* When one of these big contractors fails to deliver, the Government has to chose between suing to get their money back (or some of it) in a few years, or getting the at least part of the system they actually need at a higher price. The government doesn't need the money, it needs the system. So the contractor gets to carry on regardless of failure.
* Humans are very bad at managing small risks with large consequences. Many big disaster stories have at their heart someone who decided that the risk was too small to be bothered with.
https://wiki.c2.com/?WhyIsPayrollHard
Its from a different domain, but it gives you a flavour of the headaches you encounter. These systems always look simple from the outside, but once you get inside you find endless reams of interrelated and arbitrary business rules that have accumulated. There is probably no complete specification (unless you count the accumulated legal, regulatory and procedural history of the DVLA), and the old code will have little or no accurate documentation (if you are lucky there will be comments).