I was not clued up on the latest dev tool automation but am much clearer now, and agree with the principles set out in the article.
It’s almost impossible to talk about Agile software development without mentioning bots. If you think that's a bit of a stretch, maybe try and talk about DevOps without some sort of collaboration tool. Then realise that the two are beautifully linked. The collaborative nature of Agile means solutions like Slack are a natural …
Umm, no , it hasn't. We used it for a while then ditched it. The realtime chat was occasionally useful but eventually people just reverted to email as they got fed up being expected to be available to chat at any moment no matter what task they may be in the middle of. I'm sure if a small company has a lot of people working offsite then its great, but when most people are based in the same office building its fairly pointless and basically just a gimmick.
And no - not everyone does Agile either. Some of us prefer to have a nailed down proper functional spec before we start a major project (after doing some basic demo products) and produce a proper (mostly) finished product before the client gets to play with it, not make it up as we go along and toss half finished crap over the fence every week just because some project manager wants some visibility. Agile is amateur hour bollocks only suitable for mickey mouse toy web projects.
Using email is also nicely traceable for the business, which can be useful for showing if / when certain scenarios were considered, by who etc.
People make mistakes, so email trail showing a particular scenario was not considered is "fine" (unfortunate & regrettable, but real life possibility of fallible folk) - whereas finding it was considered but deemed insignificant is a different issue entirely (esp if its a case of a "mouthy minority" over-riding concerned majority)
My request for a project mailing list to know what everyone was doing was interpreted to mean Teams, and it's awful. What with that and Yammer which work is also pushing alongside Lync you can't get anything done. I guess some forms of IM is necessary but why do we need more constant interruptions spread across other useless half-baked programs?
But that's the idea! The consumer class back at corporate don't have any _real_ work to do, that's for the sales drones in the field and the dwindling ranks of IT hires who have actual keyboards to enter stuff like orders from customers and lines of code. Slack is Discord for hipsters, and Teams is its clone. Yammer is Twitter for a fee, because otherwise how would the social media team justify their existence. Used to be that tech would need to either be useful for selling stuff, or something that would aid the process. If you wanted stress relief you played Doom when you got home, if you craved social interaction you went to a pub: preferably after close of business. Besides, agile hasn't really been agile since the consulting class turned it into a noun, and gave the bean counters an excuse to lay off QA and the execs the freedom to avoid thinking through their requirements in detail. Dr. Demming must be turning in his grave.
Agile is amateur hour bollocks only suitable for mickey mouse toy web projects.
Meuhnon. Stop associating with low-skill IT outfits.
"Meuhnon. Stop associating with low-skill IT outfits."
I've worked on back end core systems in 4 London investment banks sunshine so I have a pretty good idea what high end IT is and how it should be done. You don't fuck about with noddy minimal spec suck-it-and-see methodologies when putting duff code into production could literally cost millions within minutes.
And no, I don't care what Ericsson think - this is the same company that desperately clung on to Erlang for decades.
this is the same company that desperately clung on to Erlang for decades
You may want to make clear why this is a bad idea, Mr. Knowitall.
Erlang is a very nice language. Choosing the C++ fad over Erlang because "we can't program anyway" was a bad move and worthy of manglement fast-profit dumbass attack.
back end core systems in 4 London investment banks
I have seen papers about QUALITY code in that area...
"You may want to make clear why this is a bad idea, Mr. Knowitall."
Not as powerful as the alternatives and lack of skills to maintain it.
"I have seen papers about QUALITY code in that area..."
I don't care what you've read, I've actually worked there and testing is stringent (perhaps less so at RBS but they're the exception to the rule).
"In my experience most Swedes are generally racists of the passive-agressive kind."
Since you apparently don't even know the difference between racism and nationalism I think its fair to say the rest of your argument is probably suspect too.
So you never have to code to detect and process such things.
I've never used slack but I'd say the coding some kind of "watchdog timer" into the process that tells someone/process "bot has been running X mins/hours/secs which is Y mins/hours/secs longer than it normally takes. Continue waiting (Y) or run recovery plan (N)"
Obviously setting (and changing it when the bot functions change) the timer number, and deciding what the recovery plan is are the big PITA's of this, but at least you know something is wrong to begin with.
It seems like IRC for Millenial DevOps w*nkers or Hipster Beardies who think its amusing to change their avatars and aliases every 5 mins.
I look forward to the day there is a pingflood tool for it just like the good old days on IRC.
Ok the comms integration is pretty good (webex etc) but its a nightmare for interrupting your workflow, and is worse than skype/lync etc for basic comms.
I was a Slack sceptic but now am a convert. It's much faster than email, doesn't have the overlapping responses problem and allows interested parties to catch up with the conversation quickly.
You can pick which topics interrupt your workflow, unlike email. The client interface is much nicer than Skype, and it doesn't try to sell you phone gateways all the time.
It's hosted IRC (so you don't have to teach people to run proxies) with an API. That's about it. That's a useful thing. It's not revolutionary.
What's happening in some companies is that it becomes used so widely that all sorts of stuff which really isn't part of its job at all is being bolted into it, because it's as convenient a place as any.
This then becomes one of those "it works fine until it doesn't" things, as the article actually did a good job of covering. If not done carefully, all those random little bits getting built on top of Slack can also be seen as a gigantic pile of tech debt that's going to cause all sorts of pain a few years down the road, when there's so many of them no-one quite remembers how they all work together any more, or even what some of them were for, or what the consequences are when they go wrong, or how to fix them...
The fact that you have now tied your business to a hosted platform with extremely questionable terms of service (last I checked, they still reserve the right to delete all your data at any time with no notice and for any reason; yes, also for paid customers) is just the cherry on top.
There are F/OSS alternatives that are worth looking into if you think the basic idea is a sound one (which, really, it is: there is nothing particularly *great* about IRC, it's a creaky antiquated protocol, and it certainly *can* be done better), like RocketChat and MatterMost.
What fascinates me with Slack is the willingness of 'modern' teams to surrender so much proprietary information to them. I've just recently left working for a financial company that considered implementing Slack for the tech teams, but the security team decided against it as too much potential confidential data would be handed over to Slack's servers in team messages to analyse and do whatever they wanted with to potentially derive resalable data metrics.
Email's a big enough distraction in the workplace without the addition of group messenger services.
Forget surrendering info to Slack, at least there's a semblance of a contractural relationship there. It's the bot ecosystem that has me running quickly in the other direction. As I understand it, and please correct me if I'm wrong:
1) Bots run on third-party servers, not under Slack's control.
2) Bots can listen to everything said in any channel they're invited to.
So basically, all these teams are inviting random bot developers to exfiltrate and mine their everyday work conversations for actionable nuggets, and it's a feature not a huge freaking security hole.
If you train a human to feed things into a system and become accustomed to not thinking about how the answer is formed, or whether it's right, or what to do if it goes wrong.. well, that basically describes most corporate procedures I've ever seen.
"I'm sorry, we can't approve this because it hasn't had sign off from Bob" - "I am Bob!" - "You can't approve your own action Sir. Rules are rules!"
The difference with a bot, is that if the procedures actually make sense, the bot won't randomly misread or disobey them, and works quickly, accurately, 24/7 - I can't say the same for humans.
*scratches head*. Not sure you got what I was trying to say:
If the procedures make sense, a bot won't randomly screw them up, unlike when you run them on a human.
If the procedures don't make sense, everyone's fundamentally fscked regardless, except good humans can bodge round it, which just means nobody then fixes the procedures.
Surely Slack will fail when they drop the free tier. That's the good news.
P.S. I came here expecting a security article. "Bots have the keys to your processes"... as in Unix processes. I suppose they do, enough to get a foot in the door. Should be interesting when that blows up!
Looks like yet another case of people trying to take work that requires proper software engineering to address and attempting to dumb it down for people who most pointedly are not software engineers.
I don't have any use for a sometimes-available external communications channel in any part of my CI/CD pipeline unless it is a round-trip integration test to an external API service used in production (like a credit card service). And my pipeline knows what do to do when there is a network failure. I have written tools that link our (paid, internal) github to our jenkins servers. And jenkins creates tickets by (gasp) making api calls to our ticketing system. Our ticketing system makes (double gasp) api calls to our mail system to let people know that these tickets exist.
Sure, you can rely on external scripts to do this stuff. But then you have to go through all the steps this article mentioned.
Would that be the proprietary, closed-source thing that's fashionable in certain circles these days?
Danke, aber nein, danke.
PS: I remember when people thought ICQ was all the rage and I should drop my XMPP server for that. I am totally not against innovation (Jabber was fresh out of the over in those days), but 18 years on my XMPP account is still online, over the rotten corpses of every other IM solution that came and went in the meantime.
As a data loss counselor, this one thing would seem most important. Funny how rarely I have seen it executed or re-tested on regular occassion. Backups can report success and still be unable to restore an item. I have heard 'backups un-usable' enough over the years to know this is a persistent problem.
It's an almighty PITA to do a full restore, endless trouble, planning, review, blah blah.
So much easier to hope it's all right and hope you never need it.
But, y'know, fail to plan or plan to fail.
Because when the s**t hits the fan PHB's love to point fingers and end careers. It makes them feel better. It's not fair, but it is what they do.
Biting the hand that feeds IT © 1998–2019