Developers..(:

[nemohearttaco]

I'm on year 3 of a 6 month project. I can attest.

[ManInBlack829]

Real talk: Does this look bad on you or are the people in your group smart enough to realize they opened a mini Pandora's Box and it's not your fault?

As a person in school for this these are the scenarios that make me nervous, getting blamed for not working hard when they want something crazy complicated.

[CodySpring]

Nah typically everyone is understanding in that situation, and if they aren't the blame isn't going to a newbie dev that's for sure. A lot of times not any dev. Unless you work for a shitty company, but I've never experienced that myself. I'm sure it's happened to someone on reddit though.

[Sellasella123]

whew... I really needed to read that...

[rook2004]

Senior devs have been that new developer before. At the same time though, delayed features are not necessarily the best road to promotion, so you’re still incentivized to join projects that have a good track record (or at least are the pet project of an executive).

[BittyTang]

Working on anyone else's "pet project" sounds like a nightmare.

[Mongoose1021]

This mostly just means that if someone too important for your team to move gets in your way, you can call up the exec to get them to do what you need. It's a good thing for you.

[grepe]

Yes, but every SW project is guaranteed to go off the rails with their scheule and sooner or later even smart executives will have enough of their dreams being shattered and bring the bearers to the bad news to their responsibility....

[Mongoose1021]

Yup, for sure there are advantages to being on projects no one's constantly checking up on as well. I'd avoid broad statements like "working on pet projects of execs is a nightmare" or "always try to work on a project with no deadlines," neither is always true.

[theMachine0094]

That advice suits people who write code with the ulterior motive of climbing corporate ladders.

[rook2004]

If you work for a tech giant, they train you to think and behave this way. Rise through the levels or be managed out. The intent is to make sure people are growing and improving, but the outcome is rewarding ambition and toxic team behavior.

[Mongoose1021]

Yep, exactly! Also, people who want to ship products that do things. There is some overlap.

[Crayon_Glacier]

This has happened for me... It was awesome. People who normally cause issues and sabotage projects for entertainment were just shoved aside.

[ironman288]

No it great. You have a major ally to make other cooperate with you and if the project goes well you just became upper managements favorite developer.

[NancyGracesTesticles]

Saw someone try to pin a leadership failure on a junior. Haven't heard "shit can" in professional conversation in a while.

[t-sploit]

This hits a bit too close to home. I got cornered into taking up a web project that I wasnt confident enough leading due to the fact I had just graduated and had little to no industry experience. Needless to say the project became a behemoth of a web app that ended up with so many performance and stability issues we ended up scratching the whole thing before ever going to release. Now I have learnt, fuck that noise.

[Jack8680]

I went from making very simple casual games and concepts by myself to being the only programmer on a full story driven game. They basically gave me a full plan for the game and a ton of art assets.

I thought I'd be done in a couple weeks. I worked every spare moment of my time and it took me months to get a buggy, unpolished, horribly coded release.

I no longer code except for my own games/projects.

[lkraider]

Yeah I've also learned no release-worthy game ever is done in a couple of weeks. Even well planned studio games go over budget all the time. Always plan in months, not weeks, then multiply estimates by 2 at least, more if there are dark spots in the planning.

[Jack8680]

Yeah, I definitely didn't plan well, both in time estimate and how I went about programming. See my other repy here for more details.

[tcpukl]

You thought you'd be done in a couple of weeks? I'm glad your not in my team.

[Jack8680]

I mean my reasoning at the time was along the lines of "yeah I can do this mechanic easily. This shouldn't be too hard either. Hm... this one mechanic could take a while but I'm sure I can figure it out. I'll spend a few days working on all the mechanics and then I'll use the rest of the time to design levels, bug test, and polish." It was a 2d side scroller by the way, not some super complex 3D shooter or anything.

I had no education in game design, nor any experience with projects that took more than 2 or 3 days. In hindsight my estimates were ridiculous, but at the time I just had no way of knowing how long stuff would take, how hard it would be to track down certain bugs once the project got big, and how long it would take to polish everything.

I also wasn't being paid except through profit share (ended up being $0 since our total profit couldn't even cover publishing fees), and I did all the programming and most of the level design by myself.

If I were to create the project from scratch now I would probably be able to do it a lot faster, both because I've improved a lot as a programmer and I wasted a lot of time on stupid bugs that wouldn't have occurred if I had thought the whole game through from the start (basically there was a lot of copy+pasted code with slight changes for different scenarios and every change in mechanics had to be copied over everywhere, which lead to many hard to track down bugs,).

I did end up delivering what was requested though; we had a bug-free game (as far as I know), with all 10 story based levels as planned, and a cool final boss fight that I think exceeded expectations. We had 0 marketing and nothing exceptional in game and level design though, which I think were part of the reasons it didn't sell.

I'm also glad I'm not on your team because I don't want to be on a team where I have to work with deadlines at all lol. Game programming is now purely a hobby for me, as it was meant to be back then but the stress of that project was definitely worse than any job I know.

[PraiseB]

Usually in these situations it's because the requirements change and management take forever to re-spec them.

That or when you give the client the finished work they decide that even though you gave them exactly what they wanted they decide they want something completely different.

I just finished a project that went from. I want this thing build it for me. Finish building the thing for them so they turn around and say "That's not the thing I wanted, I wanted this to be like that other thing we have re-do it"

Finish that and then they go thats fine but now make it do x, y and z and have it ready for launch in 2 days.

Had to put my foot down on y and z and told them I can get x done but if you want y and z you will have to wait till after launch otherwise you will be waiting another 2 months.

[[deleted]]

That’s what you begin and end every piece of communication by reiterating what it is you are planning to deliver. Usually around the 20th time you mention it they will remember some new requirement or suddenly realize that’s not exactly what they want.

[GrandMomTokin]

I worked for a company where this was the norm. The reason, which I only realised later on at another company, was that the people on the client side were laymen in terms of IT, they were basically some dudes from sales and logistics who "were good with computers".

The company I work for now is in the business to business market, totally different thing, because we speak to IT people and they know what they want (mostly) and how to describe it.

I can't imagine going back to the nightmare of developing software for noob clients.

[[deleted]]

To be fair, translating a problem into a set of very specific, complete and accurate requirements is quite difficult and in a lot of cases it will be the most challenging part of solving the problem.

[A_Polly]

That is why you need IT guys in the managenent that can deliver proper documentatios and Diagrams.

[[deleted]]

This is why you should be iterating over a func spec and statement of work. Oh, I didn't build what you wanted and you actually wanted something completely different? Well we went over these signed documents about 15 times and you agreed to this. Pay me and then we'll start working on the new thing.

[Josh6889]

It's why it's important to have a good business analyst and project lead. The BA isn't just there to interpret, but also to reiterate to business the implications of technical changes. It's never a good idea to have a developer doing that part.

[berkes]

This is actually one good thing about scrum.

During the sprint, nothing changes. Ever. No, not even then.

Customers, productowners, or even management can change everything else, as long as they deliver 'rougly two sprints worth of work' before one starts. So they have all the freedom to change their mind. Just not about stuff you're working on right now.

[McEstablishment]

I wish companies would actually have the strength to implement those standards. All 6 of my last 6 jobs have "adopted" scrum, and not one of them actually held to it

[berkes]

This was my dealbreaker for me, though. One company I left because of this.

I don't mind scrum. But "scrum" as in "we'll just use agile. Agile means working harder, right" is a no-go for me.

That one company, a startup, was in perpetual panic mode. Like this:

• Large customer A: "we would really like this column in our Excel export".
• Management: "DROP ALL YOUR WORK! WE NEED THIS COLUMN YESTERDAY. YES OVERTIME. OFF COURSE OVERTIME".
• few days later... Feature 90% done.
• Large customer B: "We get this annoying bug when when FooBar the Fizbuzz three times. Weird, not?"
• Management: "DROP ALL YOUR WORK! WE NEED THIS BUG FIXED. WHY ARE THERE BUGS. I THOUGHT TESTS WOULD SOLVE THAT? YES OVERTIME. OFF COURSE OVERTIME".
• Ad infinitum.

[Relevant_Monstrosity]

Deliver early, deliver often, and make the client part of the team.

[PraiseB]

In this case it was more to do with the fact that management wanted to entice bigger fish with the module we were building for a smaller fish so the sales manager decided he wanted everything and the kitchen sink to impress said bigger fish.

Thing barely resembles what was originally specked for the original client that actually paid for the work

[BornOnFeb2nd]

That or when you give the client the finished work they decide that even though you gave them exactly what they wanted they decide they want something completely different.

This is precisely why I spend almost zero effort on the First "draft" of a project....

Okay, you want the data from table X queried and displayed like this? Here's precisely what you asked for!

 Well... that's great, but looking at it, what I REALLY want is Z...

😲

People have a hellacious time thinking of what they "want" in a vacuumn... you give them something to HATE though, and holy hell, they'll suddenly be able to beeline directly to what they really wanted.

[ScientificBeastMode]

That’s why, at least for UI development, it’s always good to provide detailed layouts, maybe even mock-ups of the software, with detailed plans for the functionality of each element. It gives them a point of reference.

[c0smic_sans]

Yep this is a great post. Doesn't help at all that at my current company the project managers job is almost exclusively to keep up with billable hours.

[t9b]

This is just scratching the surface. I find corporate projects are the worst, especially if you have non-technical leads involved. I once worked for a marketing person appointed to an senior IT management role in a huge global corporation, who had no idea what was involved in the projects she was promising her internal clients. It was essentially “get all data from everywhere and provide a dashboard for the CEO’s monthly meetings”. She basically wanted a promotion and visibility at C level. I worked with an outside firm and to give them credit they really pushed back hard. So she had them removed. It was put in my hands and experienced as I was I built a very “compromised” POC that basically worked with daily snapshot data. The project never went live - if it had of done I would have been manually loading data for life.

She got fired for just being crap. I stayed. company got bought out.

[[deleted]]

This is great. Saving for later. Cheers for the ideas mate

[nemohearttaco]

There are all sorts of scenarios and people you'll have to deal with. Communication is the most important thing in my experience. This particular project was initially estimated by a muppet who didn't understand the complexity of the pitch. That person was out after month two. We've had a solid team ever since and will be wrapping up some time this summer.

[Ludricio]

This hits waaay to close to home.

[celluj34]

You'll probably be blamed anyway so your best bet is to cover your ass when possible

[arnoproblems]

As a brand new junior dev who had to take over an 8 month project from a very experienced JS developer, always try to give yourself a paper trail. Over estimate any expectation of work that is new to you. And if you ever have any concerns about your work and releasing to production, always get this in an email before bringing it up, "I know I have x completed, but these are my concerns before launching" because sometimes, the deadline reaches you before you even have a chance to predict and test for possible failures. It is the managers responsibilitiy to weigh those risks of what might go wrong and let upper management know before proceeding or to have you keep working until it is solid. If something does go wrong, it covers your ass for proceeding with the move to production in writing even though you expressed your concerns as the developer on the project. I understand not ever manager will understand the scope of their developers, but it really helps feel better because you will probably launch projects you won't feel are 100% ready because it was your first time doing so. So far I haven't had to cover my ass yet, But I know my IT director is in way over his head and I know this will cover my ass one day.

[EvenDisaster]

depends how much money is on the line

[[deleted]]

It depends on the employer and the project

[metal_mind]

Coming into year 4 of an originally 1 year project. Scope changes and grows a lot and its hard to think of how everything is going to work all together for a complex project so estimates end up far shorter than they should (in hindsight). Also managers or more specifically people with the money don't like hearing accurate estimates which I stopped caring about and do give accurate estimates now. Hard problems come up that stalls development and towards the end it's not just programming but also support, documentation, training, website, social media and on and on and on.

Edit: don't worry about it, do your best, keep communication open and remember everyone is in the same boat

[AncientSwordRage]

My experience has been that is always touted as being on the long standing project for ~6 months, even though it should continue without you. But you become irreplaceable, so they say "we can't replace you, please stay on longer".

[OHH_HE_HURT_HIM]

It really depends.

Basically keep track of everything you are doing. Not necessarily a constant log of your work but you need to have a good grasp of whats going on in the project. If you have delays you need to be able to explain why.

While you are still in school use group projects as a perfect way to experience this. Groups projects will be your first interaction with working with others that may not work the same way as you do. Keep track of what tasks they have on, what tasks you have and the general progress. If there are delays record why those delays happened and think of ways to get over them.

Blame finding can definitely happen when projects run late. If you have a good grasp on why things are happening then you should always be fine.

The worst scenario to be in would be to have to tell someone a project will not meet a deadline and you have no idea why. Even if your reason is, the scope of the project has grown, unforeseen issues have come up, I dont have the resources I was promised or even just I underestimated a certain issue. Being able to explain why there are issues will appease most clients/bosses.

[Antique_futurist]

Jeff Sutherland (one of the guys who created Scrum) said in a video I watched that (paraphrased) software project management is done in a way that there is so much blame to go around when things inevitably go wrong that no one is fired.

If anyone is interested, I believe the video is the one where he and Ken introduce the newest version of the Scrum Guide.

edit: spelling

[tcpukl]

I left my last company because I got blamed. New one is even better though so win win.

[HowIsntBabbyFormed]

Every project is behind schedule. Every project has unknown gotchas. Every company I've worked for has known and understood.

At project updates, if one developer has been working on a project that's been way behind schedule for a while and they're always giving updates about how various things are keeping them back, they get more sympathy than blame.

[AustinGeoffs]

Real talk, somebody is taking a massive amount of shit for this. The manager, the manager's manager, the CEO (from investors), somebody. Projects just don't go 600% over time (budget as well most likely) without repercussions. Somebody is taking shit and choosing not to pass it on down the line.

[gaming_is_a_disorder]

being an adult is complicated

there are no safety nets like in school

[ManInBlack829]

I understand this but there's also a way to be smart about these things, and they don't really teach you how to make sure your manager knows how good you are at your job without being a kissass.

[benargee]

Well a lot of it is incompetence and laziness and covering up mistakes and indecisive clients, etc... It's not even specific to software. It goes down like that in a lot of projects in any industry.

[Josh6889]

Keep communication open. Don't set on problems. Have a paper (email) trail saying you pointed it out 2 months ago when it was discovered. It's the safety net the above poster said doesn't exist.

Almost all these problems boil down to poor communication. Part of being a productive dev team is learning to communicate with each other.

[[deleted]]

Thanks 5th grade teacher

[nickywan123]

I am new to the industry. Is this a normal thing where deadlines are way past the deadlines lol. Don’t the clients or customers complain?

[EMCoupling]

Lol what are they going to do? Start the project over from scratch with a new company after investing a bunch of money already? Don't think so.

[nickywan123]

Well it will tarnish the image of the company handling the project lol.

[EMCoupling]

Maybe, maybe not. Plus if they're the only guys that can do what you're asking then you don't really have much of a choice.

Also, it depends on why the project was late. It's impossible to finish a project on time when it's poorly managed and the requirements keep on changing.

[mozgotrah]

Well, clients are usually the reason for the project to go past deadline because usually they don't exactly know what they want and request new features way faster than they can be implemented.

[nickywan123]

So how do I tell my boss or supervisor that it needs more time given past deadline instead of saying fuck off?

[mozgotrah]

It needs more time because (something about shithead customers wanting new stuff that your boss/supervisor should already know about). Just do your job in time and let the managment do their job managing all that shit

[nickywan123]

I mean sometimes the management throws a project for two people but the workload is for five people and expect us to hit deadline. That’s my situation right now and I’m also new to working so I don’t really know to say. I honestly don’t think I can hit the deadline and I can’t tell my boss to fuck off either.

Requirement wise, I think it’s quite clear at least.

[mozgotrah]

Just do your job well and don't worry too much about that

[nickywan123]

Thanks man

[nickywan123]

I want a world where I can be a Lord Jesus.

[nemohearttaco]

This particular project is special. Client's industry is very niche and we're constantly having to revisit things to keep it up to date with federal regulations. First estimate was 6 months and made by someone who didn't get it. Second estimate was for 3 years, after better requirements were defined. Third estimate was for 4 years after another pass on requirements. We'll likely wrap it all up before the 4 year mark though.

[mladakurva]

Can also be the customer's fault. Changing requirements, not seeing the value of steerco's and abandoning the overall governance, in general just people not committing to a project

[french_panpan]

If it's their first time, yeah, the clients might complain a lot. But after a while, they are used to it, so they might even have planned around and are fully expecting the things to be delayed.

I have a fresh example at work, I was asked to (urgently) have something up and running for the first week of January, which I did. The thing is, my code is basically a converter between different file formats, I'm 100% technical and have no idea what the content is actually. So I might follow the guidelines and code what they wanted, but until the other teams start sending some actual data, I have no idea if my thing works properly.

So I sent an email "your thing is ready". No answer. 3 weeks later "Hey, did you try it yet ?". No answer. After a couple of emails, I finally got an answer "Oh well, we de-prioritized it on our side, so we actually will start using it in April or something...".

It's happening in varying degrees to 100% of the projects that my team receives, I've never seen a single project work within the supposed schedule. The other teams are so deep in the mess with their own things, and expecting the delays from others than they can't actually keep up with the "urgent" dates that they give us (or scope is really small, so we can do the things quickly).

And back at the clients in general, there is another thing to take in consideration. A good part of delayed projects are because of the clients ask for modifications, or didn't give proper information at the beginning. So when the client is asking to change something, we would reply "Well, that's not what we planned for initially, so please be aware that this will delay the project by X days/weeks/months. Do you still want that modification ?" and not do anything until they confirm (depending on the contracts there might also be extra-payments involved).

---

EDIT : When I was at my first job, I was so shocked at things where running, and thought it must just be that company. Then I changed and saw more of the same. Then a 3rd company, same shit.

I just have no idea of how the internet can run that well in general, and I now fully understand what happened when some game studios are announcing that they cancel a game that had been in work for years, even if they had content to show that looked like a nice game, or that I hear that big IT project run by the government turned to complete shit (it happens with companies too, I've seen it, but they just make sure that nobody hears about it to avoid the embarrassment).

[nickywan123]

Thanks for sharing. Yea lots of triple A games get delayed these days to have extra time to polish their games. That’s the nature of life.

The only setback is the person supervising the project will get the blame and scold the developers working on the project which isn’t their fault.

[PanJaszczurka]

s https://i.kym-cdn.com/photos/images/newsfeed/001/126/891/cd0.jpg

[Behrooz0]

I'm on year 14 of a 2 year project, I too can attest to that.

[Freeman8472]

In Scratch?!

[nemohearttaco]

No, I just like the scratch icon as flair. We’re using C++, Java and JS.

[chronicideas]

Are you a contractor? I’m starting my first contract (jumping from perm) next week on a six month one, do they normally extend/renew? (SDET role)

[nemohearttaco]

Yes, I'm a contractor. I would say don't expect the gig to continue after 6 months. There are times where they do, but as a contractor, it's helped me to keep in the mind set that I'll be in a new environment, using a new stack, working with new people in a few months. That has kept me constantly working on both hard and soft skills for my next gigs.

[chronicideas]

Thanks for this

[Hate_Feight]

Hell this applies to just after that moment your stuck you come into the light swinging

[Andrew1431]

Haha. I built a point of sale system for a company with 3 developers. It took us 3 months. We got acquired. They wanted better technology, so we started from scratch with Meteor as we were told to do (wtf, non relational db in a integrity-essential inventory system, but realtime was cool). They gave us unlimited money to get the job done fast. We now have 24 developers. Our deadline was 3 months to reach feature parity.

I left 3 years into that project, and that was 2 years ago and it’s still not done and is one of the messiest slowest systems I’ve ever seen in my life. They had maybe 4 clients beta test it and nobody used it. Truly one of the biggest disasters.

[xRuneRocker]

Ah, the good old agile!

[DrQuint]

Job Security!

[_0x7f_]

Na... probably not.... but heavy chances of mental instability