Hello folks I have a question which's been raised by my latest job (rather intern). Just to put things into context - I'm 21 and I've finished my 2nd year of university before that I've had around 2 years of experience doing sys admin/QA jobs and basically I can say that I've seen how different IT sectors operated. Flash forward to present times and here's me landing an interning job at one of the premier research institution in the UK.
What I have to do is create some internal tools using a mix of technologies - mainly AWS/Java/Bash - you get the picture. Everything is OK, I'm doing my job BUT I'm not happy. Why is that - because I'm expected to work in an ad-hoc matter. That is create things quickly, without spending time on designing. My manager explicitly said that it was expected to "rush" through problems as they arise and we essentially. As a consequence it turned out that things had to be re-done and re-engineer and they are still not perfect. As far as testing is concerned - keep it to a minimum, as long as it looks working then it is OK.
Am I at fault to disagree with this way of conducting work? Is it wrong to want to think over the system as a whole, then focus on different components and see how they might inter-operate, to zero in on different "key points" which might turn out to be problematic in the future? Is it a crime to want to do a good job and not a "quick job"? Is it a mistake or wrong attitude to want to research the data structures applicable to a problem so that you can choose the best depending on a particular problem set? To the best of my understanding the "Engineering" bit in "Software Engineering" has got to do exactly with this - research your problem domain and come up with a informed solution then refine as necessary?
I've been to an interview at an Arm's office in the UK and they showed me their SCRUM room and it looked they had pretty good idea as to how to manage their project - they had a backlog, they had metrics as to how long each issue might take to resolve - the usual things for SCRUM - completely different than the way things are run "here"
Have I built a wrong idea about the software industry in general? I'd like to hear your input on that. I mean I "entered" software development purely because I want to create things - plain and simple, but I want to create quality things. I want to see my software used in various scenarios, I want to see it bullet proof - isn't that the driving force for all software engineers? I think everyone can be a programmer/coder by just learning the syntax but for me where the real fun begins is when you actually have to come up with a design which is doable in real world.
I used to do my university assignments by just looking at them and directly start coding and could easily get marks above 75% and never really appreciated the "software development lifecycle" module. But now when I saw in the real world how bad it is to work without any formal process and the frustration that is inherent in situation where you don't know if the requirements are going to change tomorrow (oh, did I say that we don't have clearly defined requirement analysis?)
I really like to believe I just landed a position where some people just needed a code monkey to do their dirty work and this is not the case how the software world operates at large.