Comments by "Edward Cullen" (@edwardcullen1739) on "Where Do The Software Bugs Come From?" video.

  1. Well, when you've had an entire system grind to a halt because a single space was in the wrong place, I call "perfectionism" being "good at my job"...
    5
  2.  @ContinuousDelivery  "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. In software, there's nothing as permanent as a temporary solution. I deliberately use the words "hack" and "bodge" to make people uncomfortable when they ask me to do this.
    3
  4. This is very true. This is why so many older devs just start working for themselves...
    2
  5. 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
  6.  @Zacpowerr  Good plan. Look at it as an opportunity to practice the art of persuasion - asking questions is a good starting point 😉
    2
  7. I'd say that's a cope from the school of "I'm god's gift to software". The biggest benefit of having some unit tests, even if coverage is poor, is that it makes bug find/fix much easier. It's also known that the most bugs appear in the least tested code... Infrastructure code testing is tricky, as it's inherently difficult to unit test. The only answer I'm aware of is to ensure that you adhere to the DevOps (sorry Dave 😉) principle of having minimal variance between environments. This is always tricky because people don't want to pay the costs of fully-duplicated environments, but that's what TF etc. are for - to enable you to stand-up and throw-away test environments "rapidly" and to maintain consistency between them.
    2
  8. Wow, what a radical concept! Surely no one already came up with this idea - say 20 years ago - because if they had, "the QA team" would be a thing of the past, right?
    1
  9. 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