Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "enterprise processes"
-
This is my most ridiculous meeting in my long career. The crazy thing is I have witnessed this scenario play out many times during my career. Sometimes it sits in waiting for a few years but then BOOM there it is again and again. In each case the person that fell into the insidious trap was smart and savvy but somehow it just happened. The outcomes were really embarrassing and in some cases career damaging. Other times, it was sort of humorous. I could see this happening to me and I never want it to happen to you.
Once upon a time in a land not so far away there was a Kickoff Meeting for an offsite work area recovery exercise being planned for our Oklahoma locations. Eleven Oklahoma high ranking senior executives were on this webinar plus three Enterprise IT Directors (Ellen, Jim and Bob) who would support the business from the systems side throughout the exercise.
The plan was for Sam Otto, our Midwest Director of Business Continuity to host this webinar. Sam had hands-on experience recovering to our third party recovery site vendor and he always did a great job. He motivated people to attend the exercise with the coolest breakfasts and lunches you could imagine. Donuts, bagels, pizza, wings, scrumptious salads, sandwiches, beverages and desserts. He was great with people and made it a lot of fun.
At the last minute Charles 'Don't Call Me Charlie' Ego-Smith, the Global Business Continuity Senior Vice President, decided to grand-stand Sam. He demanded the reins to the webinar. Pulled a last-minute power-play and made himself the host and presenter. You have probably seen the move at some point in your career. I guess the old saying, 'be careful what you wish for' has some truth to it - read on and let me know if you devRanters agree...
So, Charlie, I mean Charles, begins hosting the session and greets all of the attendees. Hey, good so far! He starts showing some slides in the PowerPoint presentation and he fields a few questions, comments and requests from the Oklahoma executives. The usual easy to handle requests such as, 'what if we are too busy to do recover all systems', 'what if we recover all of our processes from home', 'what if we have high profile visitors that month?' Hey you can't blame them for trying. You are probably thinking to yourself, 'been there - heard that!' But luckily our experienced team had anticipated the push-back. Fortunately, Senior Management 'had our backs' and committed that all processes and systems must participate and test - so these were just softball requests, 'easy-peasy' to handle. But wait, we are just getting started!
Now the fireworks begin. Bob, one if the Enterprise IT directors started asking a bunch of questions. Well, Charles had somewhat of a history with Bob from previous exercises and did not take kindly to Bob's string of questions. Charles started getting defensive and while Bob was speaking Charles started IM'ing. He's firing off one filthy message after another to me and our teammate Sam.
'This idiot Bob is the biggest pain in the ass that I ever worked with'; 'he doesn't know shit', 'he never shuts the f up', 'I wanna go over to his office and kick his f'in ass...!'
Unfortunately...the idiot Charles had control of the webinar and was sharing his screen so every message he sent was seen by all of the attendees! Yeah, everyone including Bob and the Senior Oklahoma executives! We could not instant message him to stop as everyone would have seen our warnings, so we tried to call Charles' cell phone and text him but he did not pick up. He just kept firing ridiculously embarrassing dirty IM messages and I guess we were all so stunned we just sat there bewildered. We finally bit the bullet and IM'ed him to STOP ALREADY!!! Whoa, talk about an embarrassing silence!
I really felt sorry for Bob. He is a good guy. Deservedly, Charlie 'Yes I am going to call you CHARLIE' got in big time hot water after the webinar with upper management. For one reason or another he only lasted another year or so at our company. Maybe this event played a part in his demise.
So, the morale is, if you use IM - turn it off during a webinar if you are the host. If you must use it, be really careful what you say, who you say it to and pray nothing embarrassing or personal is sent to you for everyone to see.
Quick Update - During the past couple of months I participated on many webinars with enterprise software vendors trying to sell me expensive solutions. Most of the vendors had their IM going while doing webinars and training. Some very embarrassing things came flying across our screens. You learn a lot reading those messages when they pop-up on the presenters' screen, both personal and business related. Some even complaints from customers!
My advice to employees and vendors is to sign-out of IM before hosting a webinar. Otherwise, it just might destroy your credibility and possibly your career.5 -
So it happened that a roll of my office chair broke. Since the ordering process in our company is a nightmare and takes forever AND my employer is too cheap to buy enough adequate replacement, I had to draw and print a spare part myself...9
-
Frustrated, tired and a bit lost.
I'm a "Senior PHP Backend Dev", which includes not the greatest tech stack nor the best job title, but it pays fine, and the company is awesome to work for.
I suck at writing features, but I'm great at bitching, and I easily put complex abstract concepts into usable models. So I'm also QA, tester, tech lead, database architect, whatever.
That makes writing PHP less annoying, because I create the rules, and whip devs around when they forget a return type definition or forget to handle an edge case. But I don't write a lot of code anymore, I mostly read (bad) code.
Lately I REALLY feel like doing something else... problem is that I know JS/ES6, but really dislike React/Vue and the whole crappy modern frontend toolchainchootrain of babelifyingwebpackingyarnballs. I know Python/Tensorflow/etc, but don't feel like I want to go into data science or AI. And then I'm awesome at the shit no one uses, like Haskell, Go and Rust (and worse).
I got a job offer which combines a very interesting PHP codebase with a Java infrastructure, where I could learn a lot... and I'm kind of tempted.
Problem is, everyone always shits on Java. I always made a bit of fun of Java myself. Don't even know exactly why, probably some really cruel instinct which causes kids to bully the least popular kid.
I know the basics, I've written the hello world, and a small backend app for a personal project. I know how strict and verbose it can be. I love the strictness in Haskell and Rust.... but those are both also quite terse.
Should I become a Java dev? I'm not talking about Android SDK, but an insane enterprise codebase at a life sciences corporation.
To the pro Java devs: What are the best and worst things about your job, about the weekly processes, about the toolchains? Have you ever considered other languages? Do you unconditionally love and believe in Java, or do you believe Swift, Kotlin, Scala or whatever will eventually make it completely obsolete?
Will Java hasten my decline into the cynical neckbeard I was always destined to be?
There are a lot more fun langauges, but looking at realistic demand and career value...20 -
I walk into the kickoff meeting today. The first part of this project had 5 developers and a project manager. Former project manager handled communication and sheltered us from bullshit. We built an amazing piece of software in a very short time. Customers were so amazed that they decided to reboot the project, boost the funding by several million, and let us go again. They specifically requested the same team.
Now the team looks like this: the neediest tester guy, a UX lady that doesn't have any UX background, an agile "visionary", a project manager that doesn't understand how development works, a solutions architect, 3 COTS platform specialists, a devops specialist, and an account lead. They have booked all kinds of workshops and other shit to kick things off.
So development capacity is only 60% of what it was. Management ratio was 1:5 before. Now the management ratio is 9:3. The new project manager thinks developers should be on more customer calls and responding to all customer emails during sprints. We already built this system and devops pipelines end to end. The COTS people, solutions architect, or the UX person can't program. They want us to magically convert this custom application into one based on COTS. What we need to do is make the rest of the business processes that we omitted, integrate known feedback, rework the backend, build better automated testing, improve logging and reporting, add another actor to the system, add a different authentication method, and basically work through the massive backlog.
How do they think this is going to work? Do they think we can download a custom engineered enterprise grade software system from Microsoft and double click all the way to customer satisfaction? The licenses alone are too much for the customer on an ongoing cost basis. I guess we can discuss it during the agile team-building weekend at some remote lake that the team "visionary" has set up. For the sake of fuck.
Like development isn't hard enough. Hire two more developers and lose all of the dead weight. Get a project manager that won't let the trivial shit roll down on us. What the fuck.5 -
MENTORS - MY STORY (Part III)
The next mentor is my former boss in the previous company I worked.
3.- Manager DJ.
Soon after I joined the company, Manager E.A. left and it was crushing. The next in line joined as a temporal replacement; he was no good.
Like a year later, they hired Manager DJ, a bit older than EA, huge experience with international companies and a a very smart person.
His most valuable characteristic? His ability to listen. He would let you speak and explain everything and he would be there, listening and learning from you.
That humility was impressive for me, because this guy had a lot of experience, yes, but he understood that he was the new guy and he needed to learn what was the current scenario before he could twist anything. Impressive.
We bonded because I was technical lead of one of the dev teams, and he trusted me which I value a lot. He'd ask me my opinion from time to time regarding important decisions. Even if he wouldn't take my advice, he valued the opinion of the developers and that made me trust him a lot.
From him I learned that, no matter how much experience you have in one field, you can always learn from others and if you're new, the best you can do is sit silently and listen, waiting for your moment to step up when necessary, and that could take weeks or months.
The other thing I learned from him was courage.
See, we were a company A formed of the join of three other companies (a, b, c) and we were part of a major group of companies (P)
(a, b and c) used the enterprise system we developed, but internally the system was a bit chaotic, lots of bad practices and very unstable. But it was like that because those were the rules set by company P.
DJ talked to me
- DJ: Hey, what do you think we should do to fix all the problems we have?
- Me: Well, if it were up to me, we'd apply a complete refactoring of the system. Re-engineering the core and reconstruct all modules using a modular structure. It's A LOT of work, A LOT, but it'd be the way.
- DJ: ...
- DJ: What about the guidelines of P?
- Me: Those guidelines are obsolete, and we'd probably go against them. I know it's crazy but you asked me.
Some time later, we talked about it again, and again, and again until one day.
- DJ: Let's do it. Take these 4 developers with you, I rented other office away from here so nobody will bother you with anything else, this will be a semi-secret project. Present me a methodology plan, and a rough estimation. Let's work with weekly advances, and if in three months we have something good, we continue that road, tear everything apart and implement the solution you guys develop.
- Me: Really? That's impressive! What about P?
- DJ: I'll handle them.
The guy would battle to defend us and our work. And we were extremely motivated. We did revolutionize the development processes we had. We reconstructed the entire system and the results were excellent.
I left the company when we were in the last quarter of the development but I'm proud because they're still using our solution and even P took our approach.
Having the courage of going against everyone in order to do the right thing and to do things right was an impressive demonstration of self confidence, intelligence and balls.
DJ and I talk every now and then. I appreciate him a lot.
Thank you DJ for your lessons and your trust.
Part I:
https://devrant.com/rants/1483428/...
Part II:
https://devrant.com/rants/1483875/...1 -
I got notified that tomorrow I'm gonna start a porting project from a FileNet ecosystem.
Well, I don't know what is FileNet, but at least I've enough time to study its architecture. Let's start from the official IBM page:
The FileNet® P8 platform offers enterprise-level scalability and flexibility to handle the most demanding content challenges, the most complex business processes, and integration to all your existing systems. FileNet P8 is a reliable, scalable, and highly available enterprise platform that enables you to capture, store, manage, secure, and process information to increase operational efficiency and lower total cost of ownership.
Thank you IBM, now I surely know how to use FileNet. Well, I hope that wikipedia explains me what it is:
FileNet is a company acquired by IBM, developed software to help enterprises manage their content and business processes.
Oh my god. I tried searching half an hour so far and everything I found was just advertisements and not a clue about what it is.
Then they wonder why I hate IBM so much4 -
Hello devs, I need help from database devs.
The company where I'm interning is a non IT company, so they planned to migrate to a SQL Database from their older MS Access Database.
Since I'm the only IT intern, I'm up against the major devs and hot shots from where my company outsources IT solutions.
They suggested SQL Express.
I have a meeting tomorrow with them, please help me so that I can get better results for my company.
Basically I have to question them about how their decision works better for our firm and why didn't we go for MySQL Enterprise Edition or anything which is much better and cheaper and such critical questions.
Please help me.
The Database would be used to store information about the products manufactured and their parts' history so that in future if there's a problem with the product, it can be looked up in the database so that there can be further replacement or repair processes.10 -
Long post, TLDR: Given a large team building large enterprise apps with many parts (mini-projects/processes), how do you reduce the bus-factor and the # of Brent's (Phoenix Project)?
# The detailed version #
We have a lot of people making changes, building in new processes to support new flows or changes in the requirements and data.
But we also have to support these except when it gets into Production there is little information to quickly understand:
- how it works
- what it does/supposed to do
- what the inputs and dependencies are
So often times, if there's an issue, I have to reverse engineer whatever logic I can find out of a huge mess.
I guess the saying goes: the only people that know how it works is whoever wrote it and God.
I'm a senior dev but i spend a lot of time digging thru source code and PROD issues to figure out why ... is broken and how to maybe fix it.
I think in Agile there's supposed to be artifacts during development but never seen em.
Personally whenever i work on a new project, I write down notes and create design diagrams so i can confirm things and have easy to use references while working.
I don't think anyone else does that. And afterwards, I don't have anywhere to put it/share it. There is no central repo for this stuff other than our Wiki but for the most part, is like a dumping ground. You have to dig for information and hoping there's something useful.
And when people leave, information is lost forever and well... we hire a lot of monkeys... so again I feel a lot of times i m trying to recover information from a corrupted hard drive...
The only way real information is transferred is thru word of mouth, special knowledge transfer sessions.
Ideally I would like anything that goes into PROD to have design docs as well as usage instructions in order for anyone to be able to quickly pick it up as needed but I'm not sure if that's realistic.
Even unit tests don't seem to help much as they just test specific functions but don't give much detail about how a whole process is supposed to work.9 -
2013 I guess. It's the year I jumped on the IT train. As a unix/linux sysadmin in a worldwide bank, been there for over 3 years. It was an amazing experience. Used a lot of my knowledge and learned even more. Got a chance to play around with enterprise software and hardware [remotely], deal with various vendors, have business with folks from all around the globe, learn enterprise processes, incident handling, be the initiator of automation of our processes,...
Boy it was an amazing year. In both professional and personal lives :) -
EY and ConsenSys announced the formation of the Baseline Protocol with Microsoft which is an open source initiative that combines cryptography, messaging and blockchain to deliver secure and private business processes at low cost via the public Ethereum Mainnet. The protocol will enable confidential and complex collaboration between enterprises without leaving any sensitive data on-chain. The work will be governed by the Ethereum-Oasis Project.
Past approaches to blockchain technology have had difficulty meeting the highest standards of privacy, security and performance required by corporate IT departments. Overcoming these issues is the goal of the Baseline Protocol.
John Wolpert, ConsenSys’ Group Executive for Enterprise Mainnet added, “A lot of people think of blockchains as the place to record transactions. But what if we thought of the Mainnet as middleware? This approach takes advantage of what the Mainnet is good at while avoiding what it’s not good at.”
Source : ConsenSys