There are a lot of arguments about how DoH with TLS 1.3 will give us privacy etc by the proponents of DoH(not this article).. but it’s basically moving the trust from ISPs to CDNs. There are fewer major browsers and fewer major CDNs than ISPs, I suppose.. so not sure if it’s a good move.
It was not a counter argument to anything per se. Just pointing out that even with episodes of failed estimates, there is reason to continue estimating.
Got it. Better to stick to tried and tested “boring” stuff and actually code small functionality yourself than chasing a thousand line library for trivial stuff.
At work, someone used a 3rd party library to send stats to a server in json format and “standardized” on it. 100s of developers had to now learn this new library and it’s APIs and one bug caused everyone a bit of hassle. It probably made the original dev’s job just a little easy but made it a bit hard for everyone else. These things do happen. The point is to learn from this and make better decisions over time, not give up and say we can’t get better. Trying to provide an estimate forces you to think more carefully and become better over time.
Yeah. The reason I mentioned it is to highlight that the business often needs to know what something will roughly cost and cannot just headfirst five into it. Estimation is a form of communication that addresses this.
It’s understandably a big project. But you can still start breaking it down, correct?
Break it down by services first. Then do estimates for say 2 services to get an idea of what it takes to estimate the whole thing. Part of the process is also to communicate the cost to business so that they can see if the feature is worth it or not. (Read “Shape Up” by 37signals on this. Free ebook but you get way more than what you pay).
Can’t comment too much without knowing your codebase but it is engineering. Most tasks are not supposed to be this hard. If they are, then it’s time to start paying back tech debt so you have things under control again.
Code organization (part of Architecture) matters a lot here. Especially in large code bases. Software is meant to be “soft” or pliable easily. To do that, one should be able to alter a module without having to understand the whole system. If a small task takes too long, there’s a problem with the software architecture or code organization.
Let me clarify: when I said “they are not qualified for the job” I meant they are not qualified to produce the estimate yet. They can always go back and learn what’s needed and come back with a more educated estimate (still an estimate) or they call it out as a risk item and address it ASAP. More often than not, this is because they are not ramped up (manager’s or team lead’s fault) - why else would you ask a complete newbie, regardless of seniority, to estimate?
It could be because you are working on a brand new area every single “Sprint “(or equivalent). That’s not prudent assignment of resources(the manager should know this).
I have worked in companies where ownership is somewhat static(same few folks work on a given area of the product) and things get done within 10% of estimates (a lot of innovation too).
I have also worked in terms where ownership is fluid and “resources” get assigned to tasks. Nothing is now “estimatable”. Your experience is probably in line with the latter.
It only means you didn’t do your homework(no offense, everyone falls into this trap too and conclude the issue is that estimation itself is not possible ). You can’t give an estimate based on what the task would take at your previous job.
You need to call out what you don’t know(Now, don’t give me Rumsfeld wisdom.. Most software is not that complicated)
99% of teams that need estimations are not in a phase where they are designing something that is hard to estimate. And those that are usually are prudent enough to not bother R&D with project planning(yet).
99% of engineers are working on things that CAN actually be estimated fairly accurately. New CRUD APIs? New ETLs? New React component? New integration with a product that has a published API? New service? New message format? New protocol? Whatever. Just break it down enough until it’s very clear what it takes to get it done. There will be a few unknowns but you can call them out as risks. Try to eliminate risks first and raise a flag so your manager/PM can adjust his forecast.
The thing is, everyone wants to be “working on the next big thing” so much that they actually believe they are working on something groundbreaking that cannot be estimated. Either that or they are not qualified for the job yet(hence they need to learn something new, which can be unpredictable). They just need to be grounded and it’s a fairly easy journey. They are all probably emulating the symptoms of those in 1% by believing they cannot estimate their work.
Potentially somewhat controversial take on this: why do college grads deserve a better job than, say, high school grads if the subject they studied in college is not particularly relevant to the society at this point(which the lack of jobs for that qualification is indicative of)?
There was probably a point in time when learning hunting was like going to college and along comes farming to make all those hunters jobless. That’s how the wheel of “progress” rolls.
The idea that going to college will make you more bucks or guarantees you a job in your field of study is very arcane at this point.
It’s basically modified Parkinson’s law at play - work will expand to most available workforce.
With increased automation, either new jobs are created(thereby increasing the overall output of the economy) OR expectation for individual productivity is reduced, decreasing individual stress.
History is your proof. Automation has been constantly increasing forever and there’s no job loss en masse because of that. Empirically speaking there are almost always more jobs created.
Exactly what I was thinking as I was browsing this thread. If I can understand the code by visiting as few files as possible and reading as few lines as possible and not having worry about finding those, job done.
There should be a metric that indicates aggregate LoB for a codebase. Simplistically, cluster references of all entities (variables, functions etc depending on the language), calculate the overlap of those clusters and aggregate them. Track this metric over time and when it breaches a certain threshold, refactor until it’s back to where you want it to be.
Agree with another who said it’s always the people that end up being a problem and not tech. Unfortunately a lot of tech geared towards fixing the problem ends up creating more of this because there is a new team that has to be created to add the new tech solution to the mix.
Given that, I’d like a devx stack that lets a developer go as vertical as possible without involving other people. Once you decide to add a feature, you should be able to go all the way to deployment (and iterating) without involving anybody else.
My ideal devx stack(some parts exist but some don’t)
1. Heroku like deployments everywhere in a Unix like standard fashion. If the standard exists, I’d not worry about vendor lock-in and can choose the right provider for my scale/cost etc. I’ll also be able to have the same workflows for private DCs , dev setups etc without running huge bills.
2. Heroku CI/flow/pipeline, again standardized so I’m not stuck with one vendor.
3. GitHub + VsCode (or vi or emacs or pycharm) delivered as an offline first service. With templating capabilities so you can onboard new team members with a click.
3. Expo.io like capabilities across platforms. I get it that it’s already available for iOS, Android and web. But what if I have a native app? What about a server I wrote in c/c++? Docker probably. But the updates are still not handled for me automatically.
4. As a historically backend person, I find it hard to believe it took this long for the front end world to get to the component framework. I’d like to be able to create frontend pages by just pointing to an openAPI crud spec. I want to be able to add special buttons or forms in one line (no more) by just specifying a non-crud openAPI spec.
We are almost there but not quite.
5. Since Saas is the future, All user management, subscription, engagement tracking, support, Customer pipeline etc should be a few line setups.
So I’d get up one day having dreamt of a new feature, walk to my home office in pajamas, code up the backend, specify how to expose it in the frontend, add a few test cases and click submit. It goes through testing locally, in staging, to production, gets distributed a set of people, and sends me some data on how good the dream can be by the time I finish my coffee. If I am happy I click “roll out “ And the entire world benefits from my dream.
Some companies have painstakingly built this stack. One man shows can actually do this fairly easily but mainly because the User base is small. But nothing that works for medium sized companies.