Comments by "Mentat" (@_Mentat) on "Continuous Delivery" channel.

  1. 14 hrs 15 mins of meetings this week. Just a typical week. I'm a dev and I find the most useful meetings are with 1-2 other devs and likely to be 5 mins long. The big wasters have product management and marketing in them; then it's hours of waffle.
    32
  2. The best software engineering managers are ex-devs who are ardent users of the product. They snatch code from the devs, build their own releases, and are trying out new features even before the devs have said 'done'. The worst have never even used the product, don't know how to install it, and are doing everything by numbers: lines of code, story points, whatever; they like to imagine these are telling them something.
    13
  3. I work there now! Agile has been disastrous for us. Being agile is good - but the endless rituals and ceremonies of Agile(tm) is corporate death; all creativity is killed. Innovation? Forget it. Only the Product Owner could "legally" do it, and he's got all the creativity you would expect of a middle manager.
    13
  4. It's certainly a cult. They talk of ceremonies, rituals and artifacts. And the believers have religious fervor. The Scrum Masters and Product Owners support it like their (working) lives depended on it. Which they do.
    7
  5. It often boils down to, "we took the cheapest quote." Local copies require extra nonce in each gate which means more cash.
    7
  6. I so agree. Agile itself is disastrous and very cultish, even using terms like ceremonies, rituals and artifacts. Middle managers and mediocre programmers who would otherwise be surplus to requirements cling to it like a drowning man on a log as it lets them piggyback off the abilities of others by all being "in the same team".
    6
  7. I've been doing Agile/Scrum for the last three years now. If anyone asks how it's going I say: like clockwork, i.e. if any part runs slow, everything runs slow; if any part breaks, everything breaks. It's been a disaster. The manifesto is fine but the methodology doesn't work. The power issues are valid. Scrum gives the power to business people (Product Owners) who don't know enough to decide what should be done. Engineers need to have the power if you actually want good software delivered in a timely manner.
    6
  8. Not true. We sign a contract with the customer before development starts. It's extremely rare for the customer to want changes, because with our help they correctly specify their requirements upfront.
    5
  9. Nailing down the requirement is a key waterfall skill. It's not impossible, or even particularly hard. But if you haven't got the discipline to do it I suppose you need Agile.
    5
  10.  @kevinfleischer2049  Our customers sign contracts. They could change the requirements but it would cost them. Mainly they don't. Usually we have a succession of contracts with the same customer and if they want a change or additional functionality it becomes part of the next contract a couple of years later. We're basically doing the same thing over and over again for different customers; "a hole" is not likely.
    5
  11. The killer question to the over-engineerer is: how does what you are doing make the company richer? Most of the time the answer is based on some contingency that will probably never happen. It's still amazingly hard to make them stop.
    4
  12. So true, and the root cause of so many problems. I guess the reason that this happens is because software can be life-critical or mission-critical or utterly trivial. You don't have a non-doctor telling doctors how to treat a patient because it's always life-critical. Also other professionals, doctors, lawyers, accountants, etc have personal legal liability for their work. If you had the authority to tell a doctor what to do, you would also have the 'opportunity' be gripping the rail beside him in a court when the patient dies. Happily, devs are rarely to never held responsible for their code.
    4
  13. Haha, a lot longer of course. Industry average is $50 per line of code. NASA pays $1,000 per line of code. That's the cost if you want defect free code.
    4
  14. Exactly, it means management can abdicate and not learn the software. They say you self-organize and I'll just count the story points.
    4
  15. Classical painting and sculpting were done by "teams". But it was very much students serving the master. Students were like spare paint brushes. And they didn't get their name on the finished work; there was no question of equality. I will pair program, but unless you've got my 40+ years of experience, I type and I decide.
    3
  16. Remember, tests have zero value until they discover a bug. Even when a test discovers a bug, the cost of the bug may be small, and the cost of writing the test still a net negative. I know people who are mad for tests - they have wasted the company a lot of money. I have written hundreds of tests and whenever they failed it was always a problem with the test, not the program logic. I do actually test my software though! I prefer a battery of tests from a test harness prior to release rather than coding in tests. That way you run the tests once near release, not every time you do a build.
    3
  17. My experience is that remote teams doesn't really work. You have to invest effort to overcome the hurdles so will be spending more than your competitors and eventually be put out of business; at least that's what happened when I was involved in a 3-way UK, West Coast, East Coast USA development. The company went bust and the UK team took over the entire thing and made a success of it. Remote workers are disloyal and will jump ship much faster than on-prem workers. We have 20-year-plus on-prem workers but remotes are usually gone within 4 years.
    3
  18. What the teacher meant is your way wouldn't scale, but you have to learn a scalable methodology even though a school project doesn't need it, because in the real world you will need it.
    3
  19. Don't bother, it doesn't work in the real world.
    3
  20. Rule 1: Don't use agile or scrum.
    2
  21. Customer: I'll buy your software. When can I expect delivery? Supplier: Have you heard of Agile?
    2
  22. I, a fully qualified Scrum Master, can assure you it doesn't work.
    2
  23. Mistakenly? Not necessarily. Like the F1 car that is supposed to fall apart 1 yard past the finish line, 'good' code satisfies the need and no more. Any more is programmer vanity and detracts from the profit, which the programmer should receive as a bonus.
    2
  24. I was using top-down design and writing specifications 40 years ago. We seem to have come full circle, with only the agile crowd thinking this is something new.
    2
  25. No, the mediocre partner is amazed at what "they" have produced. Someone else did the work and they share the credit.
    2
  26. Your situation seems hopeless. The best you can do is tell senior management that the methodology will never make a working system. A heroic CEO would then throw out agile and go back to methods known to work: ie, hire people who know what they are doing; put specialists into each area, and believe them when they tell you the best way to achieve the desired result; forget about "teams", individuals either deliver or you get rid. "Teams" are perfect for avoiding individual responsibility. Where I work is much the same. Agile is successfully delivering simple things but the complicated things we were going to do are continually being kicked into the future because they cannot be made using Agile. No one really acknowledges this; it's just decided "not to do that at the moment." Middle management "sold" Agile to the senior management, and it was a hard sell. And now productivity has fallen off a cliff. Senior management is getting antsy and middle management is starting to panic. Panic "looks like" we might not let you take leave; the smallest problem is a "crisis"; Agile consultants are hired and hero worshipped because they might save the day and middle management face at the same time. Engineers are forbidden from criticizing the process.
    1
  27. I scored 98% on my Scrum Master test, and I can't remember the manifesto either. 😆
    1
  28.  @leesoftwareengineer  It's 2 to 3 releases a year.
    1
  29. @luke5100 I am working on a really terrible legacy code base; a mixture of Assembler, C, C++, C#, Java and JS dating back to the 1980s in parts ;) As a developer I do endorse paranoia though. If there's a risk someone might put bugs in your code then you need to protect yourself. However, I'm also on a tight budget and code written needs to come back as £s in the bank or I don't get paid. The airy fairy nonsense starts when people have too much money!
    1
  30. Agile has ceremonies, rituals, artefacts and banishes people who point out its flaws -- it's a cult.
    1
  31. My takeaway from this is: there are no new ideas, only new names for them. In the 1980s I worked on operating systems and clearly you could never "break" an O/S call, otherwise all user programs out in the world would break. Under the covers you could do what you liked though.
    1
  32. I have tried TDD. There is a fundamental flaw in its philosophy. The user only decides what they really want when they see the software running, i.e., you have to write the code first, then demo it, then test it. TDD violates Agile.
    1
  33.  @krisztianfekete652  Unfortunately our sales dept has their own demo system developers who mock up what the customer wants and tell them the functionality they want is already 99% present in the existing product. We receive the requirements and a deadline written into a signed contract with the customer. "Let's build it together," would be rapidly followed by, "Give me my money back."
    1
  34.  @adambickford8720  It was a good company before Agile.
    1
  35. tl;dr - but I watched long enough to see it's used where its should have been used several times.
    1
  36. It would literally be illegal for doctors. Doctors have personal legal liability for their decisions. They can solicit opinions and advice from colleagues, but when it all goes wrong only one of them is going to be gripping the rail in a courtroom. Much the same is true in shpping and aviation. The captain carries the can.
    1
  37.  @YvesHanoulle  True, but only one is going to jail if it goes wrong. The others are following his orders, however much a "team" effort it may seem to observers.
    1
  38. So true. OK for teaching but you're not going to do great work in a pair - the result will always be mediocre. The pair may pick up on typos but that benefit is not worth the distraction and the time you have to take explaining your thinking.
    1
  39.  @ContinuousDelivery  This morning I spent an hour explaining the 20 line routine on the screens in front of us (remote pair programming) could not possibly be the source of our bug because on no line did it touch the list that was wrong. It took 60 minutes for her to agree something that was instantly obvious to me. We tried to fix it but she was talking the whole time and I couldn't get my head around the query required so eventually I said I needed some private thinking time and coded a fix over lunch. It seems to work, on the build server now.
    1
  40. The best methodology I ever used had a non-branch, locking, real time update, code management system. The instant you edited a file it was locked on every other developer's PC. The instant you pushed your changes every other PC was updated. You could make any change at any time without asking anyone. There were no merges obviously. You could hit build twice, a second apart, and the first time it would build and the next fail to build, because a developer had made a boo boo. You might try to edit a file and it would say "File locked by Fred." This system compelled all the behaviours Agile gurus try to instill, without ever calling itself agile. You had to negotiate to get a file; you were unpopular if you broke the build; you need to push working software only, but in little increments. There was complete freedom but also a lot of responsibility. Possibly the best bit was what Wikipedia calls the "good fairy". You could browse through the code base fixing tiny things, rewording an error message, tweaking logic. It was like working on a personal project. It made the software very good and was fast and friction-less to write.
    1
  41.  @edgeeffect  Nothing in what I wrote implied you are currently or were recently at school.
    1
  42. No, agile is big on metrics. They're called story points. Unfortunately due to the agile nature of agile development no one can say how many story points until the software is written. So in fact story points are useless. Most people really want something like: the software is 50% done. Then they add another 50% time, money, etc, to know when they will get the goods. But agile won't give you a percentage - in fact in Scrum you don't even know what you are doing more than a month or so ahead.
    1
  43. So true that. Anyone who thinks it is good wasn't there in the old days and doesn't know how it could be.
    1
  44. It's OK in small doses or for teaching. But I find there comes a time when I want to say to my pair: shut up I need to think and I can't do it with you prattling. I have said at times: sorry but I need peace and quiet to solve this, you'll have to drop off the call. It works OK with simple problems but you when need to build a mental edifice to solve the problem you need no distractions.
    1
  45.  @jacquesduplessis6175  My though is all software will be over-engineered because programmers want to; I just like everyone else. I at least know it's wrong. Just don't do it so much you bankrupt the company.
    1
  46. I have lots, I'll give you a few... 1) Free your inner Nazi: eg, don't let the user get away with errors and just ignore them. When I was young I'd ignore things that didn't make sense thinking I was being nice to the user; now I'm a Nazi and the users must get it right. The reason is that the user wanted something when they entered what they entered, and it's better to force the user to take 1 hr to get it right than have your software do the wrong thing for months on end. (I had a user, a large organisation, which had a primary data centre and a backup data centre a few miles away. For several months the backup data centre never received a single byte of data and they never realised, because they misconfigured it and the software let them get away with it. It should have refused to do anything at all until the BDC was online - that would have made them get it right.) 2) Report every error unabiguously: if a user shows you an error out of your software you must be able go straight to the line of code which generated it. Anything less is embarassing. So never use the same message twice. Also report the underlying error for every error you generate, eg O/S errors. It's also embarassing if you can't say why the error happened, eg file creation failed, don't know why - as opposed to out of disk space. 3) Bundle diagnostic tools with your kit: when a site installs your software they take it all and don't seem to care what ends up on-prem. But if they later report a problem, you may need to get a diag tool onto their site, at which point they will tell you the committee which decides if software can be installed meets on the 1st Thursday of every month and you've already missed this month. So get the diag tool in at install time or just build the diag features into the main code.
    1
  47. You are confusing SHOULD and MUST. Requirements are MUSTs. SHOULD is advice.
    1
  48. The mistake is to put rock stars in a team. They work alone. Almost any famous piece of software has a rock star behind it, sometimes two - probably not more than that. You all use Git, right? Any of you use Linux? What do you think of the Task Manager in Windows? One guy did that, and no one asked him to, they just didn't stop him.
    1
  49. With PP the higher IQ dev will get frustrated by the need to continually explain things. In my experience it's best done with an attractive member of the opposite sex -- and they're usually booked solid!
    1
  50.  @archi-mendel  Thanks for your response. It may surprise you to learn that I am a fully qualified Scrum Master. I know the process and know it doesn't work. Even on the SM course I asked the killer questions and got no answer. I asked, what does QA do while the devs are coding? What do the devs do while QA is testing? No real answers, just be idle it seems. We have a doc writer who gets a couple of hours of work per 2 wk sprint. Middle management asks for more people and senior management says we can see your engineers are not busy; so no more resources given. As for "self-organization" - the Scrum Guide is being followed to the letter, right down to how long each meeting should last; senior managers would allow deviation, but there are three layers of management between them and us. Our code base is vast and ancient. Some of it dates back to the 1980s. It runs at thousands of sensitive institutions. It is deeply intrusive; almost like delivering a replacement operating system. Really you need 20 years experience on it as an engineer to even say something sensible about it. The size of our market footprint gives us a guaranteed income and lets nonsense take hold and the recently arrived Agile fans wave their kanbans and backlogs and look like they are delivering. But nothing new has been created since they arrived. I have never dared point out to senior management it's all smoke and mirrors. The experienced engineers are leaving in disgust but no one mentions the enormous staff turnover.
    1