Comments by "Edward Cullen" (@edwardcullen1739) on "Continuous Delivery"
channel.
-
I've been really struggling with this in DevOps for a long time - everywhere I go, I end up on a "team" of individuals, working on disparate work streams, with very little day-to-day collaboration.
Sure, for simple admin stuff, this is fine, but when you have to do something complex / implement something new, I often need to spend much longer on knowledge transfer (partly because of the junior nature of my colleagues).
This is something I'm going to take a much harder line on as I think it really would be a Silver Bullet for so much; in the DevOps context, this would mean more like one person doing, the other documenting, which is at least a line I can try to placate the bean-counters...
19
-
I have some experience with low code development with one of the large (largest?) low code platforms, in a legal context.
The best summary I have, I credit to a colleague: "It's great for rapid prototyping."
From my perspective, it was just like any other tool in engineering: you end up replacing one problem with another; you're shifting the complexity around, rather than fundamentally reducing it.
Biggest problems we had was around architecture and lifecycle management.
Unlike (usually) .NET or Java (or dynamically linked C/C++), when the platform needed updating, the application needed to be rebuilt - and therefore retested.
There were also architecture problems - because the app had been developed by non-programmers, they didn't have the understanding/appreciation/experience of how GOD AWFUL ORMs can be and the dangers of accidentally slurping vast quantities of data over the network.
There were also other issues - bugs that couldn't be diagnosed and corrected by someone who understood lower-level HTTP/HTML and Java (yes, me... And I loathe Java 😂)
Another MAJOR downside was the cost - the infrastructure was EXPENSIVE, plus we had lawyers writing software... Essentially, we ended up with untestable, poorly functioning software, written by amateurs that was extremely expensive to develop and run... And a bloody nightmare to maintain!
It was great for the lawyers, because they had the sense of involvement, control and progress (all the things lawyers are predisposed to), but the cost of delivery was insane - it would have been FAR cheaper to employ a couple of good/experienced devs full-time and use cheaper infrastructure (even public cloud...)
Like I said, it would be good for prototyping: let the lawyers sketch-out something that kinda does what they want, but then had it over to experienced devs to "build properly".
16
-
13
-
11
-
9
-
5
-
5
-
5
-
4
-
4
-
4
-
4
-
3
-
3
-
3
-
@ModernSoftwareEngineeringYT "The user is always wrong."
I get really... irritated... when devs shirk their responsibilities for some aspect of the software development process. We're supposed to be the experts, so if we didn't guide/check, then how can we be surprised when we "don't get what we need"?
I think the OP's response is the same you get when devs make excuses for not doing TDD "I'm here to write code, not tests"; it stems from poor education - mis-framing of the job.
The job of a developer (or "software engineer") is to "deliver, as efficiently as possible, working software that meets the user's needs", but too many developers ("coders") see their job as "writing code" - I particularly liked your breakdown that showed devs are entirely or jointly responsible for each aspect of the software development process.
This is no different to the role of doctors in medicine - the role of the doctor is to ensure patients receive the correct care. Doctors can't blame nurses for "failing to give the right medicine" if the doctor didn't specify it correctly; they can't blame nurses for the patient dying if the doctor never checked that the patient was receiving the correct care.
The answer to me seems to be to beat this view into junior devs as early as possible, ideally pre-university.
Of course, we still have the problem of too many "software managers" who don't understand what software development actually involves, but, one problem at a time... 😁
3
-
3
-
3
-
3
-
"Whitespace indentation"
What, something that every professional developer worth his salt does as a matter of course?
Are you serious?
Coming from C, the asymmetry (no closing braces) took me about 2 weeks to get over, so I have sympathy for those who struggle with this, but my god! Complaining about indentation? Have you ever worked with other programmers?!?!
Static typing can be useful, but this argument is a crutch for poor documentation and communication between teams.
Also, if module boundaries are pain points, then simply treat arguments as "user input" and act accordingly.
Even when you have static typing, you still need null reference checks and complex inputs will need validating anyway, regardless of typing, so, where's the difference?
3
-
3
-
@TARJohnson1979 With Tom on this. History only tells you how you got here, not how to go forwards (though, it may offer hints).
People put too much stock in "history". I've had devs reject things like whitespace/line ending normalisation because it "breaks the history". Their logic being "we should perpetuate BAD, unreadable code, for the sake of history". (Also, let me introduce you to the diff option that ignores whitespace differences...)
Ironically, the argument being put forward is both "history is important" and "history isn't important"; you want a *good*, "clean" history, but you ALSO think squash commits - that erase history - are a GoodThing™.
My sense is that, in practice, there are 2 things that really matter: diffs between points-in-time (one of the few strengths of Clear Case IIRC) and blame... Sorry "annotation".
In short, I think people worry too much about this aspect of VCS. Write your code, make sensible commit comments and let the weirdos (like me) sweat over the minutiae of VCS management 😂
2
-
2
-
2
-
2
-
2
-
2
-
Is your boss a software engineer or a "software manager"? My guess would be the latter. (Though, not all "software engineers" seem able to comprehend the value of TDD...)
This is an endemic problem in the industry, sadly, as it's really difficult to get someone to understand the value of things like TDD if they've never had to fix code someone else wrote.
(One of the most overlooked benefits of unit testing/TDD is that when you have some it makes identify and verifying bug fixes much quicker...)
If you don't get a positive response, I'd recommend not over-egging, just try to do your best to implement best practice in the tasks you're given. This can be extremely tricky, so you may need to compromise until you've got enough experience to move-on.
One thing is for certain: in your next interview, ask if they do TDD. If the answer is "no", then your answer should be "thanks, but no thanks" - because you'll only be dissatisfied in the role anyway.
This is the hardest thing to do when you're starting out, but trust me, the people you WANT to work for are the people who will appreciate that question/response.
2
-
2
-
2
-
2
-
2
-
2
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
Couple of things:
"Python is the second best language for any project."
BDFL has stated "if you're worried about performance, why are you using Python?"
In this sense, Python should be used for prototyping, to understand the problem and work out how to solve it correctly. Once you have a correct solution, translating that to a performant language is trivial in comparison (plus, you have a reference implementation to test against).
Given we rarely get it right first time ("Plan to Throw One Away"), the only "performance" that matters, is getting to a correct solution.
Not strictly a Python issue, but comments in code are just like unittests: done right, with the right intent, they are GoodThing™ and should be encouraged.
Good comments give a different view of the code.
I've had many people say "you don't need comments or documentation when you have the code", but if I just want to use your code, why should I be forced to spend my time delving into your code? (which may or may not be a pleasant experience in and of itself...)
Documentation forms part of the user interface. If there is a numerical argument, I should not need to read beyond the doc comment to know what the acceptable range is.
People make the argument that "comments don't get updated". I consider this a feature, not a bug.
When there's a mismatch between stated intent in a comment and what the code does, then something, somewhere has gone wrong, potentially seriously so, therefore questions need to be asked. (And Mk1 re-education devices applied... 😉)
1
-
Sorry, but this just comes across as semantic jibberish.
You know that the the original description of Waterfall was a critique, right?
You also fundamentally misunderstand Agile.
Agile is not the absence of specification, it's the development of specification closer to the time they will be implemented; when you're doing Agile, you should still have thorough requirements specification for the features you've implemented/are implementing, you just do them together.
This differs from Waterfall, in that:
1. Doing waterfall implies up-front analysis of a problem in a changing world, where the time between analysis and implementation can be years. This leads to the problem of requirements churn, where "management" keep changing their minds as the (perceived) needs of the organisation change.
2. Developing the requirements and implementation in the light of what actually exists, rather that what "will". This works from both the business and technical perspective.
You get a new requirement that requires fundamental re-design? If you've been Agile, you'll have implemented only what you needed up to that point and so the "loss" is minimal.
SSADM/Waterfall is NO protection/guarantee against such technical redesign requirements. In fact, it was the frequency of these fundamental re-designs in Waterfall projects that contributed to the birth of Agile in the first place!
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1