4 years late, but I just started binge-watching. I wish I found your chanel earlier. It's the second project in 4 years that I'm in in which the investor is a real-state-construction king that does not understand agile and software. And boy, it's always a shitload of friction of "when will feature A B C etc. Will be ready?" And as naturally we are late on estimates, shit hits the fan all the time. Regarding the story, I got a similar one: I was appointed to gather requirements for a new software project for one of our clients, and as they were describing how they wanted some highly customizable dashboards, I stopped them and said: "You are basically asking me.to build Microsoft power BI, bit crappier and more expensive". They were speechless, as they didn't know power BI. I then quickly built a dashboard from.their database for a demo. 2 months later, they decided to licence power BI for they key managers, and hired us to build dashboards for them. It was a huge success and saved everybody money and time.
My first ever job I spent half a year (together with several others) coding a massively complex database migration for the product I was working on (new functionality required several HUGE tables to be split and new tables introduced, talking tens of millions of records throughput per day per table here). We ended up with a rather elegant solution using Cobol with embedded SQL running in parallel on multiple CPUs (this was a mainframe, multiprocessor rather than multithreading anything), with a process tracker running on yet another CPU to keep track of where each of those processes was in which table, so we could do partial commits and recover in case of a power failure. The product was built completely, tested completely by us, then by our test team, then by our internal acceptance test team, then by the customer's acceptance test team, and accepted by everyone. Project management had signed of on it. It was Tuesday afternoon, the product was to be delivered on Wednessday morning to be run on Friday evening (the entire system had to go down for this migration, and as it MUST be up 24/7 Monday to Friday software upgrades could only happen during the weekend starting 10PM friday to 2AM Monday), when we got a call from the customer. They'd gotten cold feet and considered the migration to be too risky after all, so they canceled the entire release, a release that our company had had 75 people spend half a year building (not counting design time). Everyone across both my company and the customer was happy and confident with the release, except for the one guy who had final say: the customer's release manager who'd not been involved in the acceptance testing.
Wow - what was the risk? Surely the exporting of data was non destructive for the original database? How can companies just burn millions of dollars like that?? (75x50k=3.5m so it's at least that much)
This is what I imagine happens when you work with clients accustomed to more traditional civil engineering projects, where the project can be completely planned up front.
Haven't designed a product that was never built, but I have designed and built a system that, due to company politics, never got deployed beyond the initial test systems (which have all run flawlessly for the past 4 or so years) and the company then went on to build another new version of the same system I released and are now starting to move the same test systems across to it (which will decommission the one I built). Will be interesting to see if the new one gets any traction beyond that
Sounds like oil and gas to spend loads of money but not really think about what they're buying until after the fact. I worked a summer for a mine, and I got a brand new mac to make an app no one wanted, then worked on a tablet app for the pit shop without actually asking the pit shop if they needed it (I was an idiot). That company didn't even bat an eye when a $55,000 HMI was incurably incompatible with the mega expensive MCC equipment they had installed. Worrying about it would've wasted time which the mining industry, similar to oil and gas prioritizes above all. In the end the only thing that I made that was needed and used was a redo to their 20yo website from the 90s that we all thought was abandoned but was actually kept up to date in it's original form...with banners and those gross html borders you get with s
Makes me wonder if one would be foolish asking basic questions that may be considered to be "beyond the scope of one's role". Oddly, the more senior a dev becomes, I have found myself in situations where it feels like it's an expectation to "Just shut up and do and make some progress, but don't care to what end" no matter how much your management euphimizes how creativity in your role is crucial to project success. In your case, some early survey would have been a decent predictor of the project's success, but the question is, were you in a position to make those decisions and stop if you chose to? If one is an independent consultant, how will that impact their reputation? If one works part of a larger consultancy org, will one even have a choice to express such realities and change course, or is it just a lost cause? At that point, it really becomes "How well can you sleep at night, knowing what you know?". Like being on food stamps for life.
Designed one that never went anywhere due to politics. Taught me an important lesson about how one bad leader can waste amazing amounts of money and time.
I believe that's the time to have a strong personality, learn to say NO and work on a leverage/persuasion, if requirements are not being negotiated correctly, clients/product owners/managers/analysts will invent requirements (some of them doesn't make sense) that will balloon the scope of the project, it will be over-engineering instead of MVP.
Absolutely. Even at 13 years into my career about which I was at this point, I didn’t have the skills yet to get to know the client personally well enough to get them to accept my advice. I don’t think any of us could get through to this person - they were exceptionally strong willed. 😕
I was on a similar project, except agile, but that didn't matter because they weren't really interested in customer feedback unless it validated whatever ideas the management had already thought of. And also too much time wasted trying to replicate features from competitors on a too small of a budget. I knew what this was going to be about the moment you said "reporting". Is it something about reporting and analytics software that makes managers enjoy setting money on fire pointlessly replicating it?
I am also a Software Developer by profession. In my 5 years of career, I have worked with 4 different firms and almost 10 different clients. I personally relate quite a lot with your experience and stories. Having said that, It is always good to hear what you say and I try to take something out of every video of yours. I see that it has been an year since you last uploaded your video. I would highly appreciate if you start being active again and give us more content🙂 You are helping out thousands of people like me and we look forward for more such learnings🙂
That's real unfortunate. I can't even begin to understand how you guys did the design documentation part for that long. Sounds like at that point it's accepting the situation for what it is (from your other "Accepting difficult project circumstances" video). I mean, seriously, I fail to understand the ways some organizations spend budget on things that make a negative ROI, whether whole projects or some of its underperforming teams. Few other teams in your client company must have wondered why you folks were hired in the first place. Talk about brewing animosity. I wish we got a peek into such management budget discussions/decisions or at the very least be appraised. Have you been in those discussions? Perhaps a topic request from me for one of your next videos.
Yeah these are unfortunately just some of the things that happen when people don’t trust each other’s advice enough. A prime example of why I advocate so strongly for developers to learn better communication and persuasion skills through empathy!
I learned the importance of having only one manager working at a university student union. In those things, you have a committee of what are basically kids all with different ideas and in many case are *political* rivals, then you have a general manager and us staff who are basically contract bound to never get involved in the political shit that goes on. In principle us staffers only answered to the general manager whos job was to mediate between the cacaphony of nonsense coming from the board. BUT more often then not I'd get a committee member come in and go "Hey shayne I need a website for the chess club, can you set up hosting for us", and I'd be like yep, then suddenly another student would complain Im doing that instead of whatever HE wanted me to do. In the end I just had to put my foot down and say "Put it through the GM". Later I found out the "real" world is kinda similar, you get multiple managers or general 'higher ups' with conflicting agendas or whatever , so a good project manager able to mediate between that world and the coders world is so important, so when Marketing turns up and demands you stop whatever your doing and do this instead, and then OPs turns up and wonders where the hell his database migration script is, you can point them both at your direct manager and tell them to gtfo and deal with him instead.
I took it on board when I started project managing cos I'd have a team of usually younger guys and myself and then the suits in upper management, and I saw my job as to protect the kids from the madness upstairs. If there is a complaint I take the fall because it means I wasnt managing it right. This way I can create a less stressful environment that lets the coders relax and do what they do best, write code. Expecting a 21yo to be able to stand up to a 50yo multimillionaire CEO is just unfair. But I've been around the block a few times and don't have that fear so I can mediate and build reasonable expectations in my higher ups while those under me have a clear and well articulated plan and process. Everybody wins.
@@shayneoneill1506 awesome Shayne. I had a manager for the first 12 years of my career, who I followed to 3 different companies because he was so amazing at this. When I moved to Austin and got out from working under him I had to learn some hard lessons. But the years of "protection" he provided were invaluable for helping me grow in those initial years and I'll never forget the sacrifices he made for me. I hope your team members recognize the same in you some day (if not already!). It's a noble thing to do, and incredibly effective - though the rewards for it don't often match the crap you have to deal with right??
Is it possible that the person from the client, who was in charge of the design doc, wanted all that extra "universal" functionality because they had their own agenda about a product, for which they now had an expensive first step done and they made the company pay for it?
That wasn't a failure. You delivered what the client asked for, and got paid for it. By revealing the scale of the delusion, you prevented an expensive train wreck. That you revealed to the client that they employed idiots was an additional benefit. Two related cliches apply here. The first is that you have to know the difference between civil engineering and interior decoration. The second is that successful large software projects grow from successful small projects. (The key is that when you build things (and with things) that are appropriate at the small scale don't preclude different things appropriate at the larger scale.) If you are going to build infrastructure, (roads, bridges, office buildings) you need to what, where, and how, and the numbers for how many (whatever it's appropriate to count in the context). That's civil engineering, and it needs definition but not necessarily detail down to the bottom. Waterfall, but shallow? The less adventurous the concept and the more experienced the contractor (in the specific field), the less needs to be specified in detail, as long as the critical aspects are identified. Logos, colours, some details of user interfaces and devices, user shinies in general, are interior design. Agile works well for this kind of interaction, because it allows for rapid search of the design space. An old and crafty designer may well have identified the likely areas of change, and put them in environmental variables rather than code.
I feel sorry this video has so few views. As a software developer I've had my fair share of horror stories similar to the ones you explain. I would like that some "managers" knew about these videos so they can understand why laziness, arrogance and total lack of communication are key factors to convert a project into a nightmare... mmm... no, they will never see these videos or understand that they are a huge problem... in a world were mediocre or sociopath people are ruling we can't expect them to improve to make the life of everyone better.
I’ve had good projects, just haven’t gotten to those yet. But by and large yes I’ve had more bad than good. The more people I run into who’ve been on a higher number of projects, it seems like the more common this is. But I don’t have any hard data to back this up.
@@stevengreidinger8295 people have done various studies, but they don't seem to be very broad, or reliable because the bias against reporting negatively against your employer.
Have you ever been on a project where the product was designed but never built? Have you encountered any of these situations?
4 years late, but I just started binge-watching. I wish I found your chanel earlier. It's the second project in 4 years that I'm in in which the investor is a real-state-construction king that does not understand agile and software. And boy, it's always a shitload of friction of "when will feature A B C etc. Will be ready?" And as naturally we are late on estimates, shit hits the fan all the time.
Regarding the story, I got a similar one: I was appointed to gather requirements for a new software project for one of our clients, and as they were describing how they wanted some highly customizable dashboards, I stopped them and said: "You are basically asking me.to build Microsoft power BI, bit crappier and more expensive". They were speechless, as they didn't know power BI. I then quickly built a dashboard from.their database for a demo.
2 months later, they decided to licence power BI for they key managers, and hired us to build dashboards for them. It was a huge success and saved everybody money and time.
My first ever job I spent half a year (together with several others) coding a massively complex database migration for the product I was working on (new functionality required several HUGE tables to be split and new tables introduced, talking tens of millions of records throughput per day per table here).
We ended up with a rather elegant solution using Cobol with embedded SQL running in parallel on multiple CPUs (this was a mainframe, multiprocessor rather than multithreading anything), with a process tracker running on yet another CPU to keep track of where each of those processes was in which table, so we could do partial commits and recover in case of a power failure.
The product was built completely, tested completely by us, then by our test team, then by our internal acceptance test team, then by the customer's acceptance test team, and accepted by everyone. Project management had signed of on it.
It was Tuesday afternoon, the product was to be delivered on Wednessday morning to be run on Friday evening (the entire system had to go down for this migration, and as it MUST be up 24/7 Monday to Friday software upgrades could only happen during the weekend starting 10PM friday to 2AM Monday), when we got a call from the customer. They'd gotten cold feet and considered the migration to be too risky after all, so they canceled the entire release, a release that our company had had 75 people spend half a year building (not counting design time).
Everyone across both my company and the customer was happy and confident with the release, except for the one guy who had final say: the customer's release manager who'd not been involved in the acceptance testing.
Wow - what was the risk? Surely the exporting of data was non destructive for the original database? How can companies just burn millions of dollars like that?? (75x50k=3.5m so it's at least that much)
This is what I imagine happens when you work with clients accustomed to more traditional civil engineering projects, where the project can be completely planned up front.
Exactly!
Haven't designed a product that was never built, but I have designed and built a system that, due to company politics, never got deployed beyond the initial test systems (which have all run flawlessly for the past 4 or so years) and the company then went on to build another new version of the same system I released and are now starting to move the same test systems across to it (which will decommission the one I built). Will be interesting to see if the new one gets any traction beyond that
Squirrel walking on the fence at the 3:10.
These stories are my favorite part of your channel. This one reminds me of those client budget v. client expectation memes
Thanks. I wasn’t sure if people would enjoy these or not. 👍
Found your channel yesterday and I have been watching all the videos, Thanks a lot! These lessons were never taught in my CS course :p
Thanks Vignesh! Happy you could join us 👍
Sounds like oil and gas to spend loads of money but not really think about what they're buying until after the fact.
I worked a summer for a mine, and I got a brand new mac to make an app no one wanted, then worked on a tablet app for the pit shop without actually asking the pit shop if they needed it (I was an idiot). That company didn't even bat an eye when a $55,000 HMI was incurably incompatible with the mega expensive MCC equipment they had installed. Worrying about it would've wasted time which the mining industry, similar to oil and gas prioritizes above all.
In the end the only thing that I made that was needed and used was a redo to their 20yo website from the 90s that we all thought was abandoned but was actually kept up to date in it's original form...with banners and those gross html borders you get with s
Crazy! Yeah I can relate for sure.
Makes me wonder if one would be foolish asking basic questions that may be considered to be "beyond the scope of one's role". Oddly, the more senior a dev becomes, I have found myself in situations where it feels like it's an expectation to "Just shut up and do and make some progress, but don't care to what end" no matter how much your management euphimizes how creativity in your role is crucial to project success. In your case, some early survey would have been a decent predictor of the project's success, but the question is, were you in a position to make those decisions and stop if you chose to? If one is an independent consultant, how will that impact their reputation? If one works part of a larger consultancy org, will one even have a choice to express such realities and change course, or is it just a lost cause? At that point, it really becomes "How well can you sleep at night, knowing what you know?". Like being on food stamps for life.
Designed one that never went anywhere due to politics. Taught me an important lesson about how one bad leader can waste amazing amounts of money and time.
I believe that's the time to have a strong personality, learn to say NO and work on a leverage/persuasion, if requirements are not being negotiated correctly, clients/product owners/managers/analysts will invent requirements (some of them doesn't make sense) that will balloon the scope of the project, it will be over-engineering instead of MVP.
Absolutely. Even at 13 years into my career about which I was at this point, I didn’t have the skills yet to get to know the client personally well enough to get them to accept my advice. I don’t think any of us could get through to this person - they were exceptionally strong willed. 😕
I was on a similar project, except agile, but that didn't matter because they weren't really interested in customer feedback unless it validated whatever ideas the management had already thought of. And also too much time wasted trying to replicate features from competitors on a too small of a budget.
I knew what this was going to be about the moment you said "reporting". Is it something about reporting and analytics software that makes managers enjoy setting money on fire pointlessly replicating it?
03:11 - Squirrel
I am also a Software Developer by profession. In my 5 years of career, I have worked with 4 different firms and almost 10 different clients.
I personally relate quite a lot with your experience and stories. Having said that, It is always good to hear what you say and I try to take something out of every video of yours.
I see that it has been an year since you last uploaded your video. I would highly appreciate if you start being active again and give us more content🙂
You are helping out thousands of people like me and we look forward for more such learnings🙂
3 managers hmmm did you turn in your tps report.
That's real unfortunate. I can't even begin to understand how you guys did the design documentation part for that long. Sounds like at that point it's accepting the situation for what it is (from your other "Accepting difficult project circumstances" video). I mean, seriously, I fail to understand the ways some organizations spend budget on things that make a negative ROI, whether whole projects or some of its underperforming teams. Few other teams in your client company must have wondered why you folks were hired in the first place. Talk about brewing animosity. I wish we got a peek into such management budget discussions/decisions or at the very least be appraised. Have you been in those discussions? Perhaps a topic request from me for one of your next videos.
Yeah these are unfortunately just some of the things that happen when people don’t trust each other’s advice enough. A prime example of why I advocate so strongly for developers to learn better communication and persuasion skills through empathy!
Fixed Price contracts do not work when you don’t know the project scope-I’m a PMP, PMI-ACP, CSM & CSPO
I learned the importance of having only one manager working at a university student union. In those things, you have a committee of what are basically kids all with different ideas and in many case are *political* rivals, then you have a general manager and us staff who are basically contract bound to never get involved in the political shit that goes on. In principle us staffers only answered to the general manager whos job was to mediate between the cacaphony of nonsense coming from the board. BUT more often then not I'd get a committee member come in and go "Hey shayne I need a website for the chess club, can you set up hosting for us", and I'd be like yep, then suddenly another student would complain Im doing that instead of whatever HE wanted me to do. In the end I just had to put my foot down and say "Put it through the GM". Later I found out the "real" world is kinda similar, you get multiple managers or general 'higher ups' with conflicting agendas or whatever , so a good project manager able to mediate between that world and the coders world is so important, so when Marketing turns up and demands you stop whatever your doing and do this instead, and then OPs turns up and wonders where the hell his database migration script is, you can point them both at your direct manager and tell them to gtfo and deal with him instead.
Fantastic real world analogy. Love it. Thanks for sharing.
I took it on board when I started project managing cos I'd have a team of usually younger guys and myself and then the suits in upper management, and I saw my job as to protect the kids from the madness upstairs. If there is a complaint I take the fall because it means I wasnt managing it right. This way I can create a less stressful environment that lets the coders relax and do what they do best, write code. Expecting a 21yo to be able to stand up to a 50yo multimillionaire CEO is just unfair. But I've been around the block a few times and don't have that fear so I can mediate and build reasonable expectations in my higher ups while those under me have a clear and well articulated plan and process. Everybody wins.
@@shayneoneill1506 awesome Shayne. I had a manager for the first 12 years of my career, who I followed to 3 different companies because he was so amazing at this. When I moved to Austin and got out from working under him I had to learn some hard lessons. But the years of "protection" he provided were invaluable for helping me grow in those initial years and I'll never forget the sacrifices he made for me. I hope your team members recognize the same in you some day (if not already!). It's a noble thing to do, and incredibly effective - though the rewards for it don't often match the crap you have to deal with right??
Yeah sometimes managers think that they are the only ones that want the success of the project to happen.
Is it possible that the person from the client, who was in charge of the design doc, wanted all that extra "universal" functionality because they had their own agenda about a product, for which they now had an expensive first step done and they made the company pay for it?
Anything is possible 😉
That wasn't a failure. You delivered what the client asked for, and got paid for it. By revealing the scale of the delusion, you prevented an expensive train wreck. That you revealed to the client that they employed idiots was an additional benefit.
Two related cliches apply here. The first is that you have to know the difference between civil engineering and interior decoration. The second is that successful large software projects grow from successful small projects. (The key is that when you build things (and with things) that are appropriate at the small scale don't preclude different things appropriate at the larger scale.)
If you are going to build infrastructure, (roads, bridges, office buildings) you need to what, where, and how, and the numbers for how many (whatever it's appropriate to count in the context). That's civil engineering, and it needs definition but not necessarily detail down to the bottom. Waterfall, but shallow? The less adventurous the concept and the more experienced the contractor (in the specific field), the less needs to be specified in detail, as long as the critical aspects are identified.
Logos, colours, some details of user interfaces and devices, user shinies in general, are interior design. Agile works well for this kind of interaction, because it allows for rapid search of the design space. An old and crafty designer may well have identified the likely areas of change, and put them in environmental variables rather than code.
Some great insights here, many of which have been my experience as well. I like your analogy to civil engineering. 👍
I swear to god if this isn’t the exact situation i’m in now.
Sounds like a scene from the movie Office Space
I feel sorry this video has so few views. As a software developer I've had my fair share of horror stories similar to the ones you explain. I would like that some "managers" knew about these videos so they can understand why laziness, arrogance and total lack of communication are key factors to convert a project into a nightmare... mmm... no, they will never see these videos or understand that they are a huge problem... in a world were mediocre or sociopath people are ruling we can't expect them to improve to make the life of everyone better.
Isn't this like a doctor letting the patient decide what medication they'll be prescribed?
Too many cooks spoil the broth.
Dude I feel like you have chronic bad luck in the industry haha
I’ve had good projects, just haven’t gotten to those yet. But by and large yes I’ve had more bad than good. The more people I run into who’ve been on a higher number of projects, it seems like the more common this is. But I don’t have any hard data to back this up.
@@HealthyDev That would be great data to have! Are you sure it's not out there somewhere?
@@stevengreidinger8295 people have done various studies, but they don't seem to be very broad, or reliable because the bias against reporting negatively against your employer.
Meh, just CC everyone on the same email and force them to argue it out lol. Don't waste your time trying to talk to everyone individually.
It’s a nice thought. Unfortunately as a consultant it’s our job to facilitate clarity and understanding of the project.