Someone asked me what to expect if he was to go into the development field. So I figured instead of replying to him privately, I'll reply here so that others may see just how wrong I can be ;)
I can only really comment on application development since thats what I do - we do have web developers at work, but I don't work very closely with them so I'm not sure what their environment is like. Also, bear in mind that my company currently employs over 350 people, so its a proper software development company - if you work for a smaller company, you'll probably find things are different.
As a developer, you don't just write code. All the stuff you were told at school about drawing flowcharts and crap before actually writing the program which everyone always skips is actually very important. For instance, I just started working on a new project about two months ago. Last week was the first time in those two months that I actually sat down in front of some actual code. Up until then we were doing requirements analysis and design.
Usually I have some documentation and specs upfront about what the project is supposed to do... often the docs are full of holes, which means that I'll have to go out and fill in the holes... sometimes the holes are in the actual requirements, which means I'll have to track down a Business Analyst to answer whatever questions I'll have relating to the requirements. If the spec (which is different from the requirements - the spec is derived internally from the requirements which arrive externally) has holes, then I track down whoever is responsible for the spec and go thru it with them - the requirements doc outlines what the customer wants, the spec outlines how we will deliver that to the customer. Once the spec is complete, I take that and figure out a design of the system, and produce a design doc explaining how it will work. The design doc gets sent around to everyone who may be interested in it, and they comment, and finally we have a working design. That's when I start coding.
Currently I write server-side stuff, not client front-ends. But, as part of the design process, the interface between the client and server and the server and database, and whatever else will all be defined, meaning that we can all start work at the same time, and generally we plan things so that we all reach the point where we need to actually connect to each other at the same time so we dont waste too much time. So, while I'm not a DB developer or client developer, as a team lead, i need to at least understand what they're doing so that I can co-ordinate their design as well - they'll be largely responsible for their own design work for their own components, but their designs still need to fit into the global overall design for the project.
Then once the designs are all done, we go off and start writing code - since we've got a detailed design for each component of the system, the coding isn't actually that difficult - the hard part of software development is coming up with a good enough design. Then you just translate the design into whichever language you're working with.
Then, the software goes to the testing dept for a test cycle. Part of the initial design includes preparing a test plan - as the person in charge of the project, I need to be able to identify potential areas that the testers need to focus on. More recently, in addition to shipping the software to the testing dept once we're finished with it, we also have a tester sitting with us testing the software continuously while we're developing, so that lots of bugs get identified and fixed during development. This is awesome, because the earlier a bug is spotted, the easier it is to fix. The testing dept rips it to shreds, and sends it back, along with a list of bugs that they found and steps to reproduce, screenshots, etc etc. We go thru the bug list, and decide which of them are actual bugs, which are by design, which cannot be fixed for whatever reason, which will not be fixed for whatever reason, and then finally we have a list of things to fix.
Fixing bugs can be a lot more fun than actually writing code, and it can also be a lot more frustrating than actually writing code. Especially when a bug's been in the bug tracking system for two years, and eventually you manage to figure out what was causing it, and why it could never be reliably reproduced, and then you fix it and send it thru to the testing dept, along with what was causing it, and they're now able to consistently reproduce it every time, and then they can verify that it's been fixed. And at times you can look at a bug in the list and say 'I know exactly why that's happening - it'll take five seconds to fix'.
One of the hardest things I've found about being a developer relates to time. At the start of the project you're asked for an estimate on how long it'll take. This is when you say 'I don't know' because, until you've actually hammered out a design, you really dont know what you're going to actually end up doing. Only once the design is in place are you in a position to say 'yes, this system requires these components, and each component has these sub-tasks, and I'd guess that each task will take around three days' or whatever. And then you'll find that some tasks take just a day or two, and some get you stuck on them for over a week because of something you didn't take into account in the design, or because you didn't take the two hours you spend in meetings every day, or because you just can't think clearly right now. Development is a very creative thing - you need to be in the right frame of mind for it to come right. Since it's work that requires more thought than action, it's easy to be totally off when giving estimates for timelines. That's when you end up working late to meet deadlines. Depending on how you work, the extra pressure might be a good thing... on the other hand, it might be very bad.
I don't know what else to say... I hope this is kinda what you wanted to know... if not, let me know and I'll try to elaborate on something more specific :)
Comments
Thanks dhiren, that helps a lot.
Also what qualifications do you have?
Is a BSc Comp Sci. the correct route to go?
hehe, wow, ISO ? is your company???
It has been a long time since I've heard of a company that goes into such depth with their docs etc. In the small companies it tends to fall away, or gets to a level of code-at-will type of effect. Although planning is done, but not good in any way.
I'm currently a PHP developer where I contract out to different companies. So i'm working with various teams on projects, and thus my conclusion that you guys know your stuff. Also when one has such a large company for dev, it's much easier going through the life cycle the right way than in a small company -- i think, although one may think the visa-versa is more right.....
noosh, I have a BSc Honours degree in Computer science. I'm not sure what other IT related degrees have a lot of development-type courses - try and find one where you can do as many of the dev courses as possible, but include some theory-type ones as well - they give you a much better all-round understanding of the field, even tho they may be pretty boring at times. A few years later you'll be thankful that some seemingly arb concept that you learnt in some boring theory course helps you with your dev.
Arné, I don't think we're at any ISO level officially - I know we were aiming for ISO levels a few years ago, but I don't think we were ever evaluated. I guess it depends on the size of the company and the size of the projects - for a company of our size, and the nature of our projects, we have to follow the processes or everything will just fall apart. I guess for smaller projects, we sometimes skip over some of the procedures if we know they're not going to add much value, but in general, even for those, its just safer to stick to the process - at the very least, it prevents you from becoming lazy.
I think with the smaller companies working on smaller projects the need for such complete documentation doesn't exist. At the small software house i work for there are normally only ever two developers at most working on a single project. So the need for complete documentation escapes us, mostly because we have such a complete understanding of the system we are developing. We do put alot of effort into the design spec though.
One thing that small software houses like ours is sorely laking in is testing, man i cannot stress enough how much it sucks doing your own bug testing.
And yeah like dhiren said time estimates are always the worst, i find as a developer if i have solved the problem in my head i assume it will take me no time to implement, as a general rule of thumb my boss multiplies our time estimates by three to give a much more accurate result which he can quote by.
"Great post! I really appreciate the information!"
"This is the first time I've found this site, but I'll definitely be back. It's a great resource"
Post new comment