Originally posted by: Descartes
Originally posted by: sao123
I am planning to interview for a software developer position in a local company.
The job says a developer stays with a project from project conception to support, the complete lifecycle...
but what are typically the stages of a project life?
That really depends. Not all projects go through the same phases, but if you abstract it away a little you typically have
at least the following:
Inception
Construction
That's it. Different methodologies give these areas different names, but the point is always the same. You always have to
start the project, right? That's inception. You have to actually build it too, right? That's construction.
Most methodologies are abstractions of another (e.g. UP, RUP, EUP, etc.) and simply apply different vernacular around the same ideas. SCRUM, for example, is a light project management approach that is largely just different vernacular. Most of the additions to these methods are in direct response to issues that one often encounters when building an y non-trivial application.
The point is this: You can't follow a methodology blindly.
You have to be agile (pun intended), so you have to have the tools to address problems as they arise. Trying to push a project into a mold will cause it to fail absolutely every time. There are some very specific exeptions (e.g. the team that built the Mars Lander software).
It seems to me that coding is only about 1/2-2/3 of the project itself... there's the design, modeling, then coding, and then maintenance...
Sounds good. Modeling isn't always necessary, so don't say it's a necessary part of the project. Modeling what? Some projects don't need modeling, and some shops use methodologies that expressly forbid such a process; at the very least, some forbid the idea of having an up-front modeling process and instead allow for a more emergent solution through modeling. The same applies to design.
what are the day to day activities in each stage? Whats it like to develop in a team?
If it's a good team, then it will be very interactive. If it's a bad team, then it will be a political hell and nothing but problems trying to decide even the slightest nuance. This usually involves countless emails, telephone conversations and meetings without the slightest bit of progress. It happens.
Day-to-day activities differ. My day-to-day activities are usually design meetings to go over large-scale architectural ideas that might affect a dozen or more functional areas, talking with lead developers to derive designs for key functional areas or working on key functionality that includes a strong architectural component (e.g. building a domain model, transaction support, etc.).
What are the deadlines like?
That too depends on the methodology or the shop itself. Some set their iterations to 1-4 weeks, but I've seen longer. Generally, it's a lot easier to manage a project on shorter iterations, but you can't have a one-week iteration on a project where the smallest unit of functionality takes two weeks to reasonably build, so project management has to be able to identify these metrics and create the appropriate iterations. The point is that all releases are usually timeboxed, and that box is equal to one iteration; multiple iterations equals one release.
How much coding do you do from memory, and how much do you look up in a reference manual or MSDN site?
Probably 90% from memory. I've been at it so long that I don't think there's a single area for which I'd need documentation. Most of the senior people that work with us are the same. You get to a point where development is almost intuitive; you
know what needs to be done and how without really having to think about it, and you've worked with so many frameworks/libraries that you can navigate your way around without having to really utilize documentation.
Note that this doesn't exclude documentation for the tangential things that are very important: Nuances of implementation that might affect you, exceptions, related functionality, etc. etc.
Anything you can tell me would be beneficial...
thanx.
Not sure if the above was beneficial or not, but the prevailing theme here is this: You can't put software into a deterministic approach where you simply do one thing for every other one thing. You'll find that flexibility is what's needed, and the more you embrace change the more successful you'll be.
If I were to peel away all the layers of abstraction and other nonsense about software, I think I would say that you need to think about what
everything really means. Don't think, "Do I need an elaboration phase here?" Instead think, "What's the point of the elaboration phase?" Find what's behind these abstractions and you'll find patterns in projects much more readily, and this will allow you to navigate the problem space like a pianist's fingers navigate the keyboard. That might sound silly, but I assure you it's true.
Feel free to ask me any questions if you have them.
