6 ms·

I generally see what you are aiming at, but I don't think you are weighting all aspects and showing the whole story. There could be so many different views of s

by szszrk 4y ago

I generally see what you are aiming at, but I don't think you are weighting all aspects and showing the whole story. There could be so many different views of such situation. Was it actually rebuild from scratch? Rebuilding and taking over maintenance and support are two different efforts. Why it had to be rebuilt? Was there a really unsuccessful attempt of a handover? Why was it so hard to hand over? Are we certain that documentation and training was sufficient for it to succeed? Was ongoing support taken into account? Maintenance, new features, patching, monitoring - was it hard, was it clear for others how to approach those topics? Was the architecture easy to follow and pick up by others? Expecting that others will be as genius as you may be seen as positive aim at perfection. It may also be seen as bad teamwork that will build up costs later on. Companies create standards, use "approved" frameworks and copy-paste solutions because it's then easier to support and require less people with less skill. It's hard to recruit already, you don't have to over-complicate solutions and make it even harder. Then there is a day in which your product dies on production and there is just one person who can figure out what is going on. For me it's a clear sign of poor management and we should all stay away from such practices.

gsibble 4y ago
I quit with no notice so there was no attempt to hand over. I was the only senior at the company (25+ years experience) and the rest were jrs (1-3 years). The 19 people that replaced me were juniors who developed whole new software based upon a monolithic architecture since they couldn't understand my complex Microservices based one.
fartsucker69 4y ago
the company may have decided that the product is just more important than when OP was still working there so it requires more engineers to expand it etc. however other than that if OP isn't lying I can't see any way how a 1 vs 19 situation is anything but a failure for the company lol. maybe 1 vs 2 or 1 vs 3.
- gsibble 4y ago
  I am very senior (25+ years experience) and they used all jrs (1-3 yrs). They seemed of the mindset that monkeys can write Shakespeare.
aNoob7000 4y ago
A developer leaving the company is not responsible for a successful handover or that the documentation is correct.
- szszrk 4y ago
  I want to agree with you, but actually can't. He should not be responsible. Because he already failed - he should have had that under control while he was working on it, from the very first day. Not on his notice period. We push a mentality of devops and the whole team (regardless of their position) being responsible for the final product. Push interdisciplinary attitude, where fine defined borders of each team/job fade. That developer IS responsible for that and if it's not covered by the time of his notice period it means both him and his management failed in some extent.
- fooqux 4y ago
  > A developer leaving the company is not responsible ... that the documentation is correct. I completely disagree. Documentation, however it exists, should always be correct. Whether you document by flowchart, code comments, self-reading code, or some other means, I always maintain that it should be updated as you update the code itself. Just like tests. If you only update it when you need to use it, you're missing the point of it.
  - gsibble 4y ago
    I was working 100 hour weeks and not given any time for documentation or knowledge transfer. The code was certainly self-reading but it was a very complex system, especially security wise as it was a bank. Their other developers were juniors and couldn't understand it so they threw it out and started from scratch. I quit with no notice because I was burnt out and promised a vacation when the product launched. They renegged after denying me a raise multiple times. So I left.
  - tluyben2 4y ago
    If you get paid and if there is space to do that. There is often the ‘yeah yeah let’s add the rest of the features first the do docs’. I agree with you but this often goes wrong, especially at startups.
cryptica 4y ago
>> Why it had to be rebuilt? Was there a really unsuccessful attempt of a handover? This is a good question. It could be either that management is incompetent or that the code was unmaintainable. But still, the fact that it took a team of people much longer to build does prove a point. For projects of this size, it's difficult to build them fast unless the code is maintainable, even if it's just a team of 1. There can be some extreme cases of corner-cutting which can deliver fast short term results but even this has its limits. The complexity or security issues tend to catch up with you quite quickly.
- gsibble 4y ago
  Management was incompetent and I have proof. Their stock hit a high of $15 less than six months ago. It's currently sitting at $0.66. They went from $5.5 billion to $255 million in market cap in less than six months. They had many problems.
specialist 4y ago
u/gsibble's story sounds familiar to me. People aren't rational, nothing ever makes any sense. I once build a budgeting and estimating tool (for architecture). Super simple, just worked. The PHBs brought in consultants to "solve the problem". Two years later, my tool was being used on the downlow, like some kind of contraband, because the replacement never worked. Another time, another place, I was brought in to rescue a project. Four devs spent about a year on an enterprisey monstrosity. It wouldn't even compile. Once I understood the task, I banged out a tool, using node.js & AWS for the first time, in two weeks. Then another 2 weeks to get into production. Clients were ecstatic. I have many more examples. FWIW, I'm a very average programmer; I just try to solve the problem in front of me. But I like to think I'm really good at requirements, analysis, customer communications, etc.
- japhyr 4y ago
  > But I like to think I'm really good at requirements, analysis, customer communications, etc. This goes so much farther than people think. So many people think that if they learn to write code, they'll be effective in this line of work. Writing effective code is one part of a balanced skillset necessary to do good work.

by szszrk 4y ago

gsibble 4y ago

I quit with no notice so there was no attempt to hand over. I was the only senior at the company (25+ years experience) and the rest were jrs (1-3 years). The 19 people that replaced me were juniors who developed whole new software based upon a monolithic architecture since they couldn't understand my complex Microservices based one.

fartsucker69 4y ago

the company may have decided that the product is just more important than when OP was still working there so it requires more engineers to expand it etc. however other than that if OP isn't lying I can't see any way how a 1 vs 19 situation is anything but a failure for the company lol. maybe 1 vs 2 or 1 vs 3.

gsibble 4y ago
I am very senior (25+ years experience) and they used all jrs (1-3 yrs). They seemed of the mindset that monkeys can write Shakespeare.

aNoob7000 4y ago

A developer leaving the company is not responsible for a successful handover or that the documentation is correct.

szszrk 4y ago
I want to agree with you, but actually can't. He should not be responsible. Because he already failed - he should have had that under control while he was working on it, from the very first day. Not on his notice period. We push a mentality of devops and the whole team (regardless of their position) being responsible for the final product. Push interdisciplinary attitude, where fine defined borders of each team/job fade. That developer IS responsible for that and if it's not covered by the time of his notice period it means both him and his management failed in some extent.
fooqux 4y ago
> A developer leaving the company is not responsible ... that the documentation is correct. I completely disagree. Documentation, however it exists, should always be correct. Whether you document by flowchart, code comments, self-reading code, or some other means, I always maintain that it should be updated as you update the code itself. Just like tests. If you only update it when you need to use it, you're missing the point of it.
- gsibble 4y ago
  I was working 100 hour weeks and not given any time for documentation or knowledge transfer. The code was certainly self-reading but it was a very complex system, especially security wise as it was a bank. Their other developers were juniors and couldn't understand it so they threw it out and started from scratch. I quit with no notice because I was burnt out and promised a vacation when the product launched. They renegged after denying me a raise multiple times. So I left.
- tluyben2 4y ago
  If you get paid and if there is space to do that. There is often the ‘yeah yeah let’s add the rest of the features first the do docs’. I agree with you but this often goes wrong, especially at startups.

cryptica 4y ago

>> Why it had to be rebuilt? Was there a really unsuccessful attempt of a handover? This is a good question. It could be either that management is incompetent or that the code was unmaintainable. But still, the fact that it took a team of people much longer to build does prove a point. For projects of this size, it's difficult to build them fast unless the code is maintainable, even if it's just a team of 1. There can be some extreme cases of corner-cutting which can deliver fast short term results but even this has its limits. The complexity or security issues tend to catch up with you quite quickly.

gsibble 4y ago
Management was incompetent and I have proof. Their stock hit a high of $15 less than six months ago. It's currently sitting at $0.66. They went from $5.5 billion to $255 million in market cap in less than six months. They had many problems.

specialist 4y ago

u/gsibble's story sounds familiar to me. People aren't rational, nothing ever makes any sense. I once build a budgeting and estimating tool (for architecture). Super simple, just worked. The PHBs brought in consultants to "solve the problem". Two years later, my tool was being used on the downlow, like some kind of contraband, because the replacement never worked. Another time, another place, I was brought in to rescue a project. Four devs spent about a year on an enterprisey monstrosity. It wouldn't even compile. Once I understood the task, I banged out a tool, using node.js & AWS for the first time, in two weeks. Then another 2 weeks to get into production. Clients were ecstatic. I have many more examples. FWIW, I'm a very average programmer; I just try to solve the problem in front of me. But I like to think I'm really good at requirements, analysis, customer communications, etc.

japhyr 4y ago
> But I like to think I'm really good at requirements, analysis, customer communications, etc. This goes so much farther than people think. So many people think that if they learn to write code, they'll be effective in this line of work. Writing effective code is one part of a balanced skillset necessary to do good work.