4 ms·

This is only tangentially related: I work a relatively big startup and I'm not not in the technical side of the company. A piece of "simple"* software was built

This is only tangentially related: I work a relatively big startup and I'm not not in the technical side of the company. A piece of "simple"* software was built and deployed about 4 months ago, it was a week of one developers time start to finish. Ever since deployment there has been bug after bug after bug, every time they fix one bug they break something else. This is an extremely simple system that should (in my experience as a developer) not have any problems. Does this sound normal, for every deployment to have new system breaking bugs? Does this sound something like they're letting junior developers (in skill) deal with systems beyond their scope of understanding? or is it normal for systems to be breaking frequently? This is the only company I have worked for with engineering that affected my work so I'm not sure if this is unique to this company or is common place in the corporate world.

bproctor 14y ago
I've worked at companies where this seems to happen often and it usually comes down to two things: 1) Poor communication and/or planning as far as what the end result was supposed to be. The developer built it the way they thought it was supposed to work, they find out later that it's incorrect or the specifications for it keep changing making the developer add one hack after another to get it to do what it needs to do. They'd probably like to just rewrite the whole thing, but by now it's too late. Jr vs Sr: Sr can see this coming and does whatever he/she can do to minimize it. Doesn't necessarily mean they can stop it from though, it might be too high up the chain of command. 2) Little to no testing. The developer built it and said "done" and then it was passed on to the end user. Anything of any complexity is going to be riddled with bugs if there isn't some kind of QA process in between. Developers typically suck and QAing their own work. Jr vs Sr: Sr has more experience to see possible problems before they become problems and if no QA procedure exists, will at least try to run it by a colleague before claiming it "done".
danenania 14y ago
It's hard to say without all the details. It's also the kind of thing that can be hard to gauge from outside the project. It could be new developers making rookie mistakes. It could be simple incompetence. Or it could be that what sounds simple to you on the surface balloons in complexity after being forced to fully engage with the problem and all its edge cases. If it's closer to the second, it could signify more of a failure of process than a failure of engineering if engineers are being pushed to release quickly at the expense of planning, time for refactoring, qa, unit tests, etc. That "this should be easy, why's it taking so long??!" attitude can create a toxic environment if it's coming from people who don't understand the issues involved.

bproctor 14y ago

I've worked at companies where this seems to happen often and it usually comes down to two things: 1) Poor communication and/or planning as far as what the end result was supposed to be. The developer built it the way they thought it was supposed to work, they find out later that it's incorrect or the specifications for it keep changing making the developer add one hack after another to get it to do what it needs to do. They'd probably like to just rewrite the whole thing, but by now it's too late. Jr vs Sr: Sr can see this coming and does whatever he/she can do to minimize it. Doesn't necessarily mean they can stop it from though, it might be too high up the chain of command. 2) Little to no testing. The developer built it and said "done" and then it was passed on to the end user. Anything of any complexity is going to be riddled with bugs if there isn't some kind of QA process in between. Developers typically suck and QAing their own work. Jr vs Sr: Sr has more experience to see possible problems before they become problems and if no QA procedure exists, will at least try to run it by a colleague before claiming it "done".

danenania 14y ago

It's hard to say without all the details. It's also the kind of thing that can be hard to gauge from outside the project. It could be new developers making rookie mistakes. It could be simple incompetence. Or it could be that what sounds simple to you on the surface balloons in complexity after being forced to fully engage with the problem and all its edge cases. If it's closer to the second, it could signify more of a failure of process than a failure of engineering if engineers are being pushed to release quickly at the expense of planning, time for refactoring, qa, unit tests, etc. That "this should be easy, why's it taking so long??!" attitude can create a toxic environment if it's coming from people who don't understand the issues involved.