Comments by "Slipoch" (@slipoch6635) on "Continuous Delivery" channel.

I call it watergile :)
3
Sorry but a bit of your video is a bit misleading, waterfall examples where there was large-scale successful impact: Windows MYOB UNIX Deluxepaint And so many more. I hate waterfall perosnally, and tbh 90% of businesses that claim they are agile are actually waterfall. Agile is great, but waterfall can and does work, it's more of a pain in the arse when things change after the beginning of the project, it;s slower to market, and keeping it updated after launch is a pain (usually), but saying nothing has ever been successful on waterfall is a fallacy.
3
fantastic video! Another method of documenting is setting up custom (or use existing) data annotations and make that use openapi or another system to read these to create documentation for internal use, then instill in the team that anything that is changed in the code needs the annotation changed on that function/file. The biggest issue I have seen is trust from managers in the dev team.
3
Largely this will be a matter of what the programmer is comfortable with and what languages are supported. Having used vim, vi, emacs, borland builder, VS, jetbrains etc. programming in intel x86 assembler, C, C++, C# and (wince) VB. I find the only time an IDE 'gets in the way' is when the IDE runs slow, or doesn't support a language you wish to use, or has issues compiling a particular language efficiently. For example VS pushes towards using VSC++ instead of pure C++, I find VSC++ typically ends up 4x more top heavy than say embercadero's compiled C++ solution doing the same thing. Even using another C++ compiler and a non-visual project, VS ends up taking longer and having a more inefficient binary. BUT, unless you are working at lower levels (and even then) an IDE allows for more efficient programming experience, which then you can run through the other compilers for the final binary.
2
Great video man
2
Great video, digital agencies love doing it this way (the UI enforced design), I think because they can charge clients in stages. It causes no end of issues due to misunderstandings from both FE (where FE was split from BE) and UI/X workers about the what the data they are attempting to display actually means or is for. Another problem I have come across is a lack of education of researched science in UI design courses. I have come across multiple graduates who didn't know what a mega menu was or why it was a good idea or even why menus are always along a edge border with the most important/largest change buttons in the corners.
2
Great video - cheers! I built something similar years ago for a particular project and used openapi, it was very specific to that project though. Looking into specmatic now :)
2
Yeah, while waterfall is bad for ongoing development where change occurs or scope change occurs, it has still resulted in some of the most successful software in the world today (Windows, Linux, Autodesk, Maya, Houdini etc.), and while the changes were obviously a lot more breaking at a later date, some of that was due to the way MS or whoever had built their code rules and coupling (Hungarian notation can take a running jump for example as it just adds too much complexity). TDD is great for ensuring later change does not break older code for example, many tests for coverage in certain industries are required so you can have every part of the software that takes input tested for injection attacks, buffer overflows etc. But by the same token, I believe you will start to internalise these processes as you get more experience, and some of the less necessary tests (getting an int out of the db in a model for example) are just pointless once the system is working. Agile is great for fast change & bug-fixing, but often a lot of places just get stuck in to the coding and later analysis using flow-charts shows a bunch of extra rubbish that is not needed or inefficient loops of logic. I like Agility and being able to quickly do a flowchart of the process logic and then enact the change is my fafvourite way to do things as you then have a 'map' of what is happening and any change on top of that is easier to implement as it just gets inserted where needed.
1
@ContinuousDelivery I'm not talking the current iterations of the Oses, I'm talking NT, XP round that era, a lot of linux distros were built using waterfall. Heck Unix was developed using waterfall and is the origin of the SOLID principles. We could blame Windows ME on waterfall, but that was a clusterfuck of epic proportions from the start without any specific framework or SDLC to blame (trying to jam an NT tech stack into Dos was a bad idea, keeping separate teams siloed is always a bad idea). But it is misleading to say waterfall never produced anything functional or successful, there are plenty of examples. I miss borland when they made good stuff, the new builders from embercadero are ok (prolly still more efficient than VS for C++), but very fragile and prone to breaking. Yeah anything space related had so many redundancies and backups prior to even the start of development (by the same token they did use the research->analysis-> design -> implementation steps of waterfall) that I am not surprised they approached it using methodology that would be termed TDD.
1
Hmm, well the bloke at MS I know was working waterfall post NT4. Unsure what specifically on but he's an assembler programmer so it would be very low level boot/driver/OS work. I'm unsure why you think a small team means waterfall wasn't followed? I was part of a 3 person team working on application software and we had to do the project using waterfall. Doesn't matter anyways it just seemed an odd assumption. Os2/warp (round 95 days) was actually pretty decent IME but IBM never bothered to really push it for non-business use which is a shame as it was working considerably better than Win 95 and pre-sp2 98. Getting decent software for it was a bugger though. One of the more famous groups that used waterfall for many years (They may still) was Toyota (kanban boards were used within their waterfall system) for their manufacturing software. Cisco has and still uses both Agile and Waterfall for different things. As mentioned earlier a LOT of older 3d rendering and engineering/architectural software was developed using waterfall. I have worked in several jobs where full-functional software has been released and 1 major version has been supported and updated over more than 10 years and it was developed using waterfall. I have also worked agilely in small and larger teams and have also supported original waterfall projects using agile for updates. Now patching, updating, anything with ongoing development and large change etc. I prefer to use Agile, but if we want a robust code structure for a new project particularly if the end-user is not going to be involved in the development at this stage, then I think it's either CI with a shedton of qualitative & edge case tests and code reviews/pair programming (or other fallbacks to reduce poor code quality) or map the planned software out using a waterfall methodology, if you then use agile for the implementation stage, this is fine, but the amount of crap I have seen in code where one thing has been done a few different times in the same codebase because a new TM didn't know it had already been done elsewhere is pretty much something I see on every agile project I have worked on (none have been CI/CD). The rate of this issue occurring in waterfall was greatly reduced as there is less unplanned change. perhaps you could do a vid on your fave methods for ensuring the existing team is replaceble with others that do not have full code coverage and how you would structure something so that the wheel is not reinvented for a new feature when it exists elsewhere even when it may not be obvious? I go with the flow for the most part. If I find we need a lot more planning I'll do the planning. If something is a pain to modify each time we touch it, then I will flowchart it, mapping out what it is actually doing and every point of the software that touches it. If it is small change I will just get stuck in and do it. If it is large I will change the flowchart and try to push it to be more modular and efficient (and more obvious). The above has resulted in one piece of layered agile import code, instead of taking 2-3 hours (often getting timeouts) and using 4-6gb of RAM, to taking 10 minutes and using 500MB. It also avoided a couple of edge-case gotchas later on that would have killed it (and would not have been caught by the tests) when the data imported was a bit weird (this was a very oddly designed data set and was very mutable, but the client had no control over it) . Horses for courses, whatever is the simplest way to make it a robust long-term solution should be the way to follow. Usually I use agility, but for more planned, less mutable work I will use a general overview waterfall with agile for the actual implementation phase and to handle any change to the overall plan.
1
How would you go about removing changes that do not work without affecting other changes when not using a feature branch? (assuming there are commits after the bad code has been submitted)
1
@ddanielsandberg and if you have a large set of features that needs removal AFTER deploy? for example a client has asked for some feature, we have implemented it then it needs to be removed cause it is a breach of internal policy (for the client), or is not what they were actually after? (Yeah I know the spec for a feature should be done and checked, but we have had the client change their mind after the fact), now you either have a whole feature that is just hidden with a bunch of extra code, which is not great, or you have to remove it, removing the branch merge is easy enough and should affect later commits by other people, but when it is part of trunk it can be...a git.
1
@ContinuousDelivery SO if you have a large feature where you need to 'break' how the db works for example, you would do all the work to get it up and running using the new system (lets say you are moving from EF to NoSQL because you don't need sharding and all the other overheads MSSQL imposes), or would you implement the first steps, then commit, and work on all the object bases and interface calls to update them to use the new system and commit as you go leaving the overall trunk in a broken or semi-broken state? In the above example someone may be simultaneously working on some controller additions to get a viewmodel using some calculated data alongside some DB model data, in the case of small commits & CI, their work will now not function until the particular model they are pulling in to the controller works and the DB calls/functionality are updated. In the case of the above with the changes made between just EF & EF Core there can be a LOT of hidden gotchas (like whole db methods no longer working the same way) so it can be time expensive to go around hunting all the places it may fail. So person B (controller work) now has what could have been a quick change being delayed, but only if person A's changes are being pulled into their code.
1
Yeah it's basically the SEO market for management.
1
great video, really interested in your messenger object system too.
1
Huh, I have practised this with product managers (digital agency PMs) to explain why something is a bad/good idea, never knew there was a method that used it too (rule 34?). Particularly the cost to not implement a change.
1
@koderkev42 I agree, in my compsci degree I learnt ways of thinking and planning that I use on a daily basis that often a lot of web programmers (BE/FE) who have not studied just have never learned, things like GC optimisation in C#, minimising loop logic, for loops vs foreach, using UML/flowcharts to find problems in logic. Unfortunately in a lot of FE positions they just do not think of these things and so JS libraries have to pick up the slack, and often end up using a lot more memory that they need to. Even little things like someone wanting to use a JS MVC FE framework with a C# MVC BE, you already have the MVC structure in your system, adding that framework just duplicates half the work and doubles the points of failure when change occurs.
1
pfff, 623 line function, I had to debug a vb (I know, I know) library, it had 3 functions each of which had 40 params and over 1000 lines; It was essentially the same code in each with a few minor differences too. After refactoring I got it down to 500 lines total in the library in multiple small functions. ;)
1