-
Isn’t this just a frustration with the fact that so many packages depend on so many packages? Because the same rogue actor stuff would apply to any tree dependency self-published system. See your local Gemfile. Do you really know what’s being installed?
So what’s the proposed fix? Stop depending on so many packages?
Perhaps there should be a line drawn for the major packages, to use less of these tiny modules.
But this is also part of the beauty of single responsibility packages. Composing extremely simple parts is all we really need, right?
Think about all of the tiny programs you run on your Unix machine of choice. Perhaps those are also at fault for the “too small to be worth it” sin.
Again, where do we draw lines?
-
The elm package manager will refuse to publish a package that violates semantic versioning. So if you’re a malicious actor, changing the API of some package for nefarious purposes, you’d be doing a bit of a hard job because since functions can’t change their signatures without you bumping the major version and since most elm-packages.json files will not update major versions automatically, it becomes harder to ship evil code. Also, a simple elm-package diff command would tell you what changed between versions, making it easier for you to audit the code. There is a lot of beauty in it. It is not evil proof, but it makes it a bit harder.
-
I wonder if you can push this to an extreme, where each public function is independently versioned. Then you could upgrade to a new version even if there are breaking changes, as long as they’re not in any part of the API you use. I’m not sure if it would be useful but its a fascinating idea.
-
-
-
I just took a look at the Gemfile for one of my websites and there are a lot of gems but ~80% come from the rails team and most of the rest are trusty sources like amazon. This is not even close to as bad as when I created a blank Vue project that already had thousands of packages many about 3 lines long.
-
Good heuristic. Still possible to see bad stuff come down the pipe, but perhaps not as common just by way of community.
Could we imagine the same thing happening, though, in a parallel universe? I think so.
Then again, standard libs for Ruby do a lot of the small stuff for you. Even/odd come to mind.
-
Ruby seems to have lots of mega libs that do big tasks but JS devs seem to have taken the path of making a new package for every function. I do wonder how often JS devs add 2 packages that do the same thing because they forgot about the last one. The result is also that questions online about ruby often tell you to use methods built in to ruby or ActiveSupport where as JS questions either get you to build it yourself or use jquery.
-
In defense of ActiveSupport, you can include individual pieces of it at whatever granularity you like, and the documentation explicitly calls this out to you at the very beginning.
Even in projects that are not web-related, I sometimes bring ActiveSupport along but will onlyrequire 'active_support/core_ext'and add things later if I need them as the project grows (often things liketime_with_zoneornumber_helper).I think that it’s a good way to balance “provides a lot of stuff” and “forces you to use all of its stuff”. I want to complain that the rest of Rails’ sub-projects don’t provide the level of utility when included gradually, but I also appreciate that that is the whole bargain: Rails’ perceived productivity boosts are derived from a tight coupling that pays dividends, you as long as you go with the Rails Way.
Edit/Afterthought: Over the years, some of the better Ruby libs to hit this balance of providing a lot but allowing for gradual or clean interop (with other libs, or with your application code) have been those authored or worked on by Piotr Solnica.
-
-
-
-
What I do in my Python work is generally be willing to depend on large, tested projects with well established, thriving communities that have a good history of responding to security incidents. These packages usually do not depend on other packages or when they do, on well established ones (e.g. requests library).
I might include other, less known packages, if I intend to use most of their functionality and if it is not easy to replicate on my own. Otherwise I write my own version or copy with attribution and license only the relevant parts.
This is not perfect, but gives me some confidence that things will be fine.
It is also an approach that completely breaks down in my Javascript/Typescript work because of so many packages being pulled in and everything seemingly depending on everything else (yes, I am exaggerating).
-
The problem already starts with licenses. For many apps for example you’ll have to list the licenses of all used libraries, and the libraries, including all transitive dependencies in the UI.
For my Android app that’s a few dozen overall, and it took only a few hours to do this. For even the smallest Angular project, this is insanity.
So if you want compliance, you’ll need to throw the entire ecosystem out right now. Or you just violate the licenses. Often even projects such as angular have dependencies that have no license.
-
-
-
Just wanted to pop in and thank you for including Developer Tea on the list. Certainly humbled to be on a list with these other incredible shows!
-
inactive-user
edited
5 months ago
|
link
| on:
Collection of Important Podcasts for Software engineers
Would you consider breaking the podcasts down into categories, or expanding on what areas, topics, and expertise each offers? Otherwise it’s just a big list of sometimes descriptive names.
Edit: which I would contribute to, but I don’t listen to tech podcasts at this point, so at best I could just copy/paste whatever their website says. If you’re a long time listener, your summary is much more valuable, and really the core value here in my approximatarion.
-
Very strong opinions here…
As far as I’m concerned, strong scrum practices would defeat these issues.
Bad tools are not scrum. Lack of ownership is not scrum.
People who try to use scrum as a way to wrap a process around bad ideas will never benefit from it.
Take the good ideas, apply scrum, and most importantly, adapt to what you learn.
Umm. Point 5 and 6 of TFA?
I’ve learnt from seeing it in practice both in my own experience and speaking to many others… The article is pretty spot on.
Ok. Warning. Incoming Rant. Not aimed at you personally, you’re just an innocent bystander, Not for sensitive stomachs.
Yes, some teams do OK on Scrum (all such teams I have observed, ignore largish chunks of it). ie. Are not doing certified scrum.
No team I have observed, have done as well as they could have, if they had used a lighter weight process.
Many teams have done astonishingly Badly, while doing perfect certified Scrum, hitting every Toxic stereotype the software industry holds.
Sigh.
I remember the advent of “Agile” in the form of Extreme Programming.
Apart from the name, XP was nearly spot on in terms of a light weight, highly productive process.
Then Kanban came.
And that was actually good.
Then Scrum came.
Oh my.
What a great leap backwards that was.
Scrum takes pretty much all the concepts that existed in XP…. and ignores all the bits that made it work (refactoring, pair programming, test driven development, …), and piles on stuff that slows everything down.
The thing that really pisses me off about Scrum, is the amount of Pseudo Planning that goes on in many teams.
Now planning is not magic. It’s simply a very data intensive exercise in probabilistic modelling.
You can tell if someone is really serious about planning, they track leave schedules and team size changes and have probability distributions for everything and know how to combine them, and update their predictions daily.
The output of a real plan is a regularly updated probability distribution, not a date.
You can tell a work place bully by the fact their plans never change, even when a team member goes off sick.
In some teams I have spoken to, Scrum planning is just plain unvarnished workplace bullying by powertripping scrum managers, who coerce “heroes” to work massive amounts of unpaid overtime, creating warm steaming mounds of, err, “technical debt”, to meet sprint deadlines that were pure fantasy to start with.
Yes, if I sound angry I am.
I have seen Pure Scrum Certified and Blessed Scrum used to hurt people I care about.
I have seen Good ideas like Refactoring and clean code get strangled by fantasy deadlines.
The very name “sprint “ is a clue as to what is wrong.
One of the core ideas of XP was “Sustainable Pace”…. which is exactly what a sprint isn’t.
Seriously, the one and only point of Agile really is the following.
If being able to change rapidly to meet new demands has high business value, then we need to adapt our processes, practices and designs to be able to change easily.
Somehow that driving motivation has been buried under meetings.
I 100% agree with you actually.
I suppose my inexperience with “real certified scrum” is actually the issue.
I think it’s perfectly fine and possible to take plays out of every playbook you’ve mentioned and keep the good, toss the bad.
I also love the idea that every output of planning should be a probabilistic model.
Anyone who gets married to the process they pick is going to suffer.
Instead, use the definitions to create commonly shared language, and find the pieces that work. For some people, “sprint” works. For others, pair programming is a must have.
I think adhering to any single ideology 100% is less like productivity and more like cultish religion.
Haha. Deadlines suck so let’s have em every 2 weeks!
As they say in the XP world: if it hurts, do it more often.
True. It’s a good idea. One step build pipeline all the way to deployment. An excellent thing, all the pain is automated away.
If you planned it soundly, then a miss is feedback to improve your planning. As I say, planning is a data intensive modelling exercise. If you don’t collect the data, don’t feed it back into your model… your plans will never improve.
If it was pseudo planning and a fantasy deadline and the only thing you do is bitch at your team for missing the deadline… it’s workplace bullying and doing it more will hurt more and you get a learned helplessness response.
Warning: plain talk ahead, skip this if you’re a sensitve type. Scrum can actually work pretty well with mediocre teams and mediocre organizations. Hint we’re mostly all mediocre. This article wreaks of entitlement; I’m a special snowflake, let ME build the product with the features I want! Another hint; no one wants this. Outside of really great teams and great developers, which by definition most of us aren’t, you are not capable.
This the best thing about scrum/agile imo. Getting someone higher in the food chain to gatekeep what comes into development and prioritize what is actually needed is a huge benefit to every developer wether you realize it or not. If you’ve never worked in a shop where Sales, Marketing and Support all call their pet developers to work on 10 hair on fire bullshit tasks a day, then you’ve been fortunate.
The problem is: Scrum also keeps people mediocre.
Even brilliant people are mediocre, most of the time, when they start a new thing. Also, you don’t have to be a genius to excel at something. A work ethic and time do the trick.
That said, Scrum, because it assumes engineers are disorganized, talentless children, tends to be a self-fulfilling prophecy. There’s no mentorship in a Scrum shop, no allowance for self-improvement, and no exit strategy. It isn’t “This is what you’ll do until you earn your wings” but “You have to do this because you’re only a developer, and if you were good for anything, you’d be a manager by now.”
Inverting the cause and effect here is an equally valid argument, that most developers in fact are disorganinzed, talentless children as you say, and the sibling comment highlights. We are hi-jacking the “Engineer” prestige and legal status, with none of the related responsibility or authority.
Is there mentoring and clear career paths in none scrum shops? This isn’t a scrum related issue. But regardless, anyone who is counting on the Company for self actualization is misguided. At the end of the day, no matter how much we would all like to think that our contributions matter, they really don’t. To the Company, we’re all just cogs in the machine. Better to make peace with that and find fulfillment elsewhere.
Scrum does not assume “engineers” at all. It assumes “developers”. Engineers are highly trained group of legally and ethically responsible professionals. Agile takes the responsibility of being an engineer right out of our hands.
I love this definition. I have always said there’s no such thing as a software engineer. Here’s a fantastic reason why. Computer programmers may think of themselves as engineers, but we have no legal responsibilities nor ethical code that I am aware. Anyone can claim to be a “software engineer” with no definition of what that means and no legal recourse for liars. It requires no experience, no formal education, and no certification.
True, but why?
IMHO, because our field is in its infancy.
I dislike this reason constantly being thrown around. Software engineering has existed for half a century, name another disipline where unregulated work and constantly broken products are allowed to exist for that long. Imagine if nuclear engineering was like us. I think the real reason we do not get regulated is majority of our field does not need rigor and companies would like a lower salary for engineers, not higher. John Doe the web dev does not need the equalivalent of a engineering stamp each time he pushes to production because his work is unlikely to be a critical system where lives are at stake.
I’m pretty sure that most human disciplines date in the thousands years.
Nuclear engineering (that is well rooted in chemistry and physics) is still in its infancy too, as both Chernobyl and Fukushima show pretty well.
But I’m pretty sure that you will agree with me that good engineering take a few generations if you compare these buildings with this one.
The total lack of historical perspective in modern “software engineers” is just another proof of the infancy of our discipline: we have to address our shortsighted arrogance as soon as possible.
We’re talking about two different things. How mature a field is not a major factor in regulation. Yes I agree with your general attitude that things get better over time and we may not be at that point. But we’re talking about government regulating the supply of software engineers. That decision has more to do with public interests then how good software can be.
I’m not sure if I agree.
In my own opinion current mainstream software is so primitive that anybody could successful disrupt it.
So I agree that software engineers should feel much more politically responsible for their own work, but I’m not sure if we can afford to disincentivate people to reinvent the wheel, because our current wheels are triangular.
And… I’m completely self-taught.
While I agree with the idea of this, you did point out that this works well with mediocre teams and, IME, this gatekeeping is destructive when you have a mediocre gatekeeper. I’ve been in multiple teams where priorities shift every week because whoever is supposed to have a vision has none, etc. I’m not saying scrum is bad (I am not a big fan of it) but just that if you’re explicitly targeting mediocre groups, partitioning of responsibility like this requires someone up top who is not mediocre. Again, IME.
Absolutely, and the main benefit for development is the shift of blame and responsibility to that higher level, again, if done right. Ie there has to be a ‘paper trail’ to reflect the churn. This is were jira (or whatever ticketing system) helps, showing/proving scope change to anyone who cares to look.
Any organization that requires this level of CYA (covery your ass) is not worth contributing to. Leeching off of, sure :)
So are you saying that scrum is good or that scrum is good in an organization that you want to leech off of?
I was referring to the case the gp proposed where the gatekeeper themselves are mediocre and/or incompetent, and in the case scape goats are sought, the agile artifacts can be used to effectively shield development, IF they’re available. In this type of pathological organization, leeching may be the best tactic, IMO. Sorry that wasn’t clear.
I’m in favour of having a product owner.
XP had one step better “Onsite Customer” ie. You could get up from your desk and go ask the guy with the gold what he’d pay more gold for and how much.
A product owner is a proxy for that (and prone to all the ill’s proxies are prone to).
Where I note things go very wrong, is if the product owner ego inflates to thinking he is perhaps project manager, and then team lead as well and then technical lead rolled into one god like package…. Trouble is brewing.
Where a product owner can be very useful is in deciding on trade offs.
All engineering is about trade offs. I can always spec a larger machine, a more expensive part, invest in decades of algorithm research… make this bigger or that smaller…
Then there is a sadly misguided notion, technical debt.
If he is wearing a project manager hat, there is no tomorrow, there is only The Deadline, a project never has to pay back debt to be declared a success.
If he is wearing a customers hat, there is no technical debt, if it works, ship it!
Since he never looks at the code….. he never sees what monsters he is spawning.
The other blind spot a Product Owner has is about what is possible. He can only see what the customers ask for, and what the competition has, or the odd gap in our current offering.
He cannot know what is now technologically feasible. He cannot know what is technologically desirable. So engineers need wriggle room to show him what can or should be done.
But given all that, a good product owner is probably worth his weight in gold. A Bad One will sink the project without any trace, beyond a slick of burnt out and broken engineers.