Comments by "Tiago D\x27Agostini" (@tiagodagostini) on "Continuous Delivery" channel.

The classic terminology from the 60's, ORTHOGONAL requirements is the best one. They are not laid upon the axis of actuation of the system, but they are Still requirements.
1
The classic term from software engineering are ORTHOGONAL REQUIREMENTS. because they are orthogonal to the task the system performs (in the very algebric sense of the word). That terminology is way better.
1
@RaMz00z What kill companies is market , management, regulation and govnnrment shenannigans. Abstraction cannot do that. Bad abstractions make a company SLOW. Alone they are not enough to kill a company. Obviously you want good ones, but engineers tend to overestimate how much their critical path is ALL the critical path of a company.
1
@madmanX1314 I have 20 years on software development and took me only 3 years managing a company to understand why the pressure comes for certain things. The problem usually arises in middle, then middle management do not understand either side and create procedures to pretend to achieve what he THINKS his boss asked. Will give you an example, here in the fiscal mode MY company works( vary on each country and each modality) we need to PREDICT the expenditure on the semester in paychecks used for new products and maintenance (Because the taxation is different).. so we need to have a reasonable prediction if something is deliverable before a clear cut day of the semester or not. If we make it wrong, we pay more taxes... believe, managing a company is NOWHERE simpler than writing code (on both cases due to difficulties created by other humans).
1
The end result is the same. The strongly typed language has a chaperone that points when you make a mistake. But the mistake is still you that make. It has been years sicne last time I had an error in python of an entity of wrong type reaching a location. But that is mostly the developer developing the paranoia needed for that tool (i.e the damn parameters indicate very clearly what should be passed). Strong typing is very useful helper tool, but all mistakes are always made by a developer.
1
I have been watching all your videos in the last 2 weeks or so, and the more I read people comments and examples, the more I realize we as "development field" have a problem. We, frequently think as development as a domain , when in reality it is a function upon different domains . An example was your statement in this video... "it is a fairly complex system and take sup to 25 minutes to build from scratch". I come from a background where a compilation from scratch takes like 3 hours, Our test datasets had more than 700 GB of data and the testing as a whole took yet a few more hours (and COSTS quite a bit of money to execute) . That just raises a point for me, we usually take OUR reality as the reality of development and that is as much a mistake as is when marketing and other departments take their realities and try to shoehorn it into development. There is no such thing as the reality of development, each company and field will have very different conditions that will result in different needs!
1
@ContinuousDelivery It is production data because there is statistical and AI inference about data in the product and we need to test if in a real workload it keep within certain boundaries (and Tomosynthesis exams have a few GB each one). Sure probably there is along path of optimization but you need to survive and hold on while you trail that path. Each domain has its different minefield to navigate. I bet Space X teams would love if testing a rocket engine was cheaper :)
1
That is specially true because in a legacy system you not always knwo what is expected at each point or component output, but you know with a larger degree of certainty what is expected at the end of a LARGER group of components or system.
1
Specially because in several fields the clients DEMAND proof of end to end testing. When someone says do not do what your clients DEMAND, there is something wrong.
1
@grrr_lef well if I have no time limit and the pay is really good I might try it :P Also more on the subject.. you cannot tell your clients to get lost. That is not how successfull companies work, besides what holywood might think .
1
That said a modern engine has built in self monitoring. That is what unit test would be in that scenario. That said , it is true, You cannot write ALL the tests before you advance a bit in your development, it is as bad as writtign ALL the code before writting any test.
1
OOP is so BAD that any other paradigm is superior just for the fact that it keeps people away from the church of the absurd object hierarchies.
1
The greatest advantage of having independent systems is that you can test and evaluate (not only feature test, but business test) a new approach for something more easily. Obviously the limit is that you cannot have the tool (the architecture in this case) cause more effort than the job itself.
1
On your example at 14:06.. no way in hell. The first example ios EXPLICIT.. Explicit is always more clear (and is superior in avoiding someone stick something mixed with it (that is very easy to do in that loop)
1
That is the root of my whole problem with a practice that puts TEST as driving the development. Tests are important but are not the DRIVE factor or you deturpe the objective of your development. People start to skew the design just so they can get better Test coverage numbers and not solve the client problem in the best way.
1
@jangohemmes352 Git is super problematic with notebooks because it does nto understand which lines are code and which are execution results (they are there intermixed). So when you make a pull over one of your own versiosn that was running in other data.. it nearly always result is HUGE number of conflicts and you spending half your day trying to fix it. We need a version control tool that knows how to handle notebooks safely, until then we need to believe everyoen using the notebook remembered to erase every single cell of execution before a commit and that is well like believing in santa claus
1
@antoruby Yes there are, but the more pieces you need to put in a system to work, the more chance something would go wrong. I really wish git had soemthing embedded for that in the sense that it ignores certain things in merges.
1
@a0flj0 But that has always been my critic.. TDD preachers draw it as a holy salvation that by itself can assure nothign ever goes wrong. I hate when people put techniques in front of the main objective.. delivering a good product.
1
@Immudzen That is the correct approach (unless you are designign a library as a product, then forethinking on the interface is warranted)
1
@a0flj0 Some 30 years of career here.. and I never found a TDD preacher that did not treat it as the holy path of salvation, at the level that "junior developers that do TDD do better code than senior ones without TDD." I blame the universities here, they teach content as if it were gospel and not technique. Sad byproduct of bad education system in places where universities are public and the teachers cannot ever be fired.. so they never update and keep repeating the same last thing they learned jsut before they go their job.
1
@a0flj0 Well my 20+ years in the field have been basically only repetitions fo these anecdotals. I never seen anything different from that (I know they do exist, but my point is that it is NOT TDD that makes it work.. it is a set of more relevant maturity and education aspects).
1
The development branch being almost a mirror of the master is indeed useless. But branching when an experimental large change is being made is critical. If you are trying something that you might want to throw away you should NEVER EVER do it in a place where other people receive that before you can decide if you want to go forward.
1