Comments by "" (@defeqel6537) on "Continuous Delivery" channel.

@thoroughsoft I think Kanban is pretty close to what you describe (edit: also, Scrum's Product Owner is pretty close to your BA description), but I also think that clarifying the requirements is an invevitable part of software development, and often the fewer layers of communication there are between the one to define the requirements and the one to implement them, the better, assuming both are competent communicators.
1
Yup, we gave up on that, still need to try to estimate other things as it helps to prioritize things, but if we knew the cause of the bug well enough in advance to estimate it (and how to fix it), then we would have done it already.
1
I'm not sure if data oriented programming is really a programming paradigm as much as software design, although those things are deeply intertwined anyway. Data oriented is also something simple on the surface, but gets quite complicated in practice, though I still like to lean towards it. I like to use multiple paradigms as they best suite the situation, which is why I generally like C++, despite its problems.
1
@ContinuousDelivery Yeah, and I think being both honest and assertive about the state of the project, and the requirements, helps here. That said, everyone always seems to be about limiting their own work as much as possible, even when we try to create metrics to show both our progress and technical debt, those are never followed by the business people, even if they have been the ones to request those metrics.
1
My (as practical as I can make them) learnings: 1) abstract the platform with the requirements you have, but learn from existing abstractions (there is a reason POSIX APIs tend to use byte streams, and HW interfaces tend to use memory addresses); both specificity and generality are important, and usually at odds with each other 2) test your system's behavior using automated tests 3) tests should run quickly and produce repeatable results 4) the "unit" in unit tests is the test, and does not relate to the size of the code/system under test 5) (at least) for unit testing, use in-memory (fake) implementations of abstracted platform services, avoid "mock testing" where you specify behavior on test-by-test basis 6) get feedback for your system as early and as often as possible (see continuous integration, continuous deployment) 7) use a source control system 8) neither implementation code, nor test code is holy, feel free to remove code and tests when no longer needed (changed requirements, or test case covered by another test) 9) prefer removing code to modifying code when behavior / specification changes 10) learn software patterns and anti-patterns, and their "when, where and why"s 11) spend time learning new APIs with Proof of Concept implementations before implementing them Additionally: - learn to communicate with other people, this includes your code, some diagramming skills can help - find comfort: whether talking about production environment, testing systems, build systems, programming languages, frameworks & APIs, editors, keyboard or key mappings, do your best to reduce discomfort / friction in your day-to-day
1
Learning your editor/IDE is one of the easiest way to up your productivity. Programming isn't just about writing code, but you should be able to write quickly enough for the typing to not get in the way of your thinking. And yeah, templates and snippets and such can be helpful for this too. That said, it's funny how many of the features here are just trying to fix the clunkiness of writing Java.
1
Nah, Scrum is better than Waterfall, and DOES have some useful concepts (though not unique to it), but I cannot say it is especially great "in full". The Story Point concept is especially harmful, since it is a waste of time beyond "tiny", "I can do this", "who knows", and easy to misuse (and yes, this is a problem of the process)
1
@davetoms1 yeah, technically they aren't part of the modern Scrum, but in practice are always there, whether we are talking about abstract points, days, hours, whatever (edit: and to highlight why it is less of an issue in modern Scrum is that it recommends breaking the backlog into tasks taking one day or less, while before it just recommended estimating tasks and filling the sprint using those estimations)
1
@ContinuousDelivery this is exactly how I feel too, async attempts to hide the actual control flow by infiltrating every level of the code. The Erlang engine is more honest about the control flow. The only async implementation that I've somewhat liked so far is boost::fiber, though I hear Go's is similar.
1
Yup, definitely been there, done that. There were good reasons, but not good enough to do so at that stage of development (if ever).
1
Indeed. The Linux kernel wouldn't count as open source based on that definition, as far as I can see
1
I would disagree with the assertion that higher level tests are more fragile in the face of change. Unit tests should test a piece of reusable code, a component. If the code is specific to another system, there is absolutely no need to unit test it.
1
@ContinuousDelivery AFAIK it depends on the operation performed, and a lot of them are still done "manually". Like every major surgery involving ligaments IIRC (smaller ones are wholly different). But yes, eventually surgeries will be done by robots & AI, but it will take longer.
1
@ContinuousDelivery I'm agreeing with you, just pointing out that AI helping with general practice is quite different from more complex tasks, involving unexpected situations, thus "more difficult". In fact surgery is one of the best places for this.. conversion.. as it is not much different from assembly line operation, and can be converted to robotics relatively cheaply (in both physical resources and energy).
1
That's part of what I consider as the danger of "Agile". Not going slow enough to enforce a) good architecture and a.2) good tests, so you can b) refactor the code into something more manageable. We have that issue too, to some extent; "chasing the feature", where the constant push for having features done by X date (only to have the specification change later), and then pushing on more and more feature without giving the code a chance mature. It takes real effort and confidence from the team to say "no, we cannot do that and keep our code clean enough to be workable next year too".
1
@Timur21 to me that sounds like a great way to CREATE bugs while fixing them Personally I think that the unit of code under test should be a module that has more than a single client, whether that client is the end user or another module. If only a single other module is the user, then those modules should be tested together.
1
@Timur21 not having enough tests for the existing functionality while fixing bugs is prone to creating new bugs
1
@ContinuousDelivery my biggest problem with Scrum is exactly that people who do not understand Agile abuse it, e.g. having the management fix both a timeline and goals, but then still push more work on the team in the name of being Agile. Basically forcing upon the team the worst parts of Waterfall and Agile, while limiting the benefits. I haven't actually tried Kanban, but I feel like it better reflects management needs while forcing them to prioritize requirements.
1
They are correct. There will always be jobs, simply because complex AI is costly, and moreover complex robots are costly, and will remain so due to resource and energy constraints. That said, those jobs may not be high paying.
1
How would you approach User Stories for a more distributed system? Let's say you have multiple services of which one handles a connection to some IoT devices, and another concerns itself with the user view of the data collected from the IoT device, from the perspective of the IoT device itself should the user stories be told from end user perspective or from system perspective (keeping in mind that IoT team might not know how the data is used by the services)? So, is it: "As a user, I would like to see temperature data from the device, so I know the component is not overheating" Or: "As a service, I would like to acquire temperature data from the device, so I might show it to user in some form" Or something else?
1
Tests should be written on the feature-level, the implementation details don't matter. This is not always possible, but I'd say in 99% of cases it is. Not that I'm convinced that branches should be avoided, but I do think that frequent merging would be useful (again, in 99% of cases), but needs to be done right.
1
@Mio2k10 I agree, and disagree. Generally, yeah, fully refined increments should be preferred, but as long as it is flagged out, or similar, I'm starting to see a benefit with WIP state changes being merged too. I do think merging WIP requires care though, otherwise may lead to just frustrating your team members. As for testing, my point was that the tests (usually) shouldn't rely on what the code looks like, so they may be written quite early on, after a bit of planning. As for test types, I prefer unit tests, by which I mean code I control the inputs and outputs for. IMO people should avoid micro-testing, where they try to test each function or class separately (unless those are your deliverables, in which case thoroughly test them).
1
@TheEvertw managers: "we were selling the product to a customer, and promised it could do X, implement X in the next 2 weeks, so we can make a sale"
1
@TheEvertw that's assuming you have a PO, and that they are not one of the managers / sales people
1
One issue affecting this is how SCRUM systems usually assigns tasks/USs to specific people, and it's not possible to add them to multiple people. This then leads to silo'd workflows.
1
A) We are pretty much stuck with feature branches on an organizational level - we are trying to keep our branches small and frequent though (still not perfect, but we are improving), in the end, communication is key here whether on the individual feature-branch level or when talking about the "complete" feature and the plans for it B) I fear CI is too straightforward (for a lack of a better word) - you either need really good pairs programming together to avoid silly and/ or hard to find bugs creeping in, especially as less capable developers are just as capable of breaking tests as any other part of the code - you miss that part of separation that a pull request and review gives you; this is personal, but I can better focus on reviewing changes and trying to figure out what they affect when I go into code review for a (small[ish]) PR. This is also true of my own PRs. This, I think, is especially true when your code deals with multiple concepts that you need to mentally context switch from. I'm fully willing to accept that this might be my prejudice talking, since I haven't really been involved in a real CI project thus far. edit: I do adore your videos though, including this one
1
You are basically describing what he did in the video though.
1
I often do this with new code as well
1
@ rarely have I needed to refactor everything, in fact that sounds like horrible design, but the cases Dave went through weren't caused by any of that, they were mostly redundancy failures, or just plain programmer incompetence
1
Very good video overall, if for nothing else than to give some food for thought, like many of your videos. Often enough I find the decision on how to approach development isn't as important as the shared understanding of why that decision has been made, and what other options have been considered and the reasons they were rejected. edit: I find a comparison between BDD and Hungarian Notation somewhat interesting, as the idea of both, as far as I can tell, is to represent intent and not specifics, and both are used incorrectly (granted, much of the latter is better described using type systems)
1
8/8
1