To take a devil's advocate side, you don't have to list everything on your resume. ;)

I had a job a prof helped me get during college. I had no idea what I was getting into, and I couldn't finish it during the summer. The company understood, since they knew my experience, and kept me on until I could finish it. Looking back now (12 years ago), I would consider it a complete failure, but it was great experience!

Do not be afraid to take a job, especially if you are looking for experience. They know you don't have experience, and are a student. Just make sure there isn't any legal ties to negligence.

The worst thing that will happen is you get fired, and you probably won't use that on your resume. Either way, you get a taste of a real project, and that really goes a long way. It will make you take a different look at your classes, and understand the importance of things, especially Software Engineering.

I say do it. Surprise yourself and grow from the experience. Plus it beats working at McD.

Quote:
I say do it. Surprise yourself and grow from the experience. Plus it beats working at McD.

There's attacking a more or less reasonable problem with some experienced coworkers to act as mentors and to learn working in a team, and some reasonable managers, and failing. There's a lot to be learnt from that.

Then there's attacking a wholly unsolvable problem on your own under management that's shown to be anything but reasonable by posting such a job offer in the first place, and without more experienced coworkers you could learn either skills or teamwork from.

Quote: The company understood, since they knew my experience, and kept me on until I could finish it.

This job offer says a lot about the people making it: it says they know nothing about the difficulties you'll face, and it says they expect something for nothing. Ignorance and stinginess are not traits I value in an employer.

You'll learn about failure, and about extremely bad vibes in the workplace, but not much else.

Failure is hard even when you almost got there and when those you disappoint are reasonable people who appreciate your hard work (supposing you actually did work hard).

Trying to satisfy the unreasonable expectations of people unqualified to recognize either incompetence or excellence in your field will teach you bitterness, but I doubt it'll teach you programming or anything else worth knowing (with the possible exception of 'never ever willingly accept a position as a fool's subordinate if you take pride in your work').

Why not tell them their project is infeasible and negotiate it down to something much more realistic? I don't know what the arrangement is like at your school, but you might be able to work it out such that you continue to consult for them part-time after the summer. Get them to agree on a smaller core feature set - new routing system interfacing to old dispatch system via a bridge/adapter, and minimal AJAX UI to manage it - and implement that over the summer. Then, through the fall/winter semester(s), roll out new pieces incrementally.

The experience you'd gain would be incredible: negotiating, long-term development, incremental deployment, maintenance and updates...

Of course, it'd be better for them to just hire a full-time programmer who's not in college, but if they want to be cheap and you feel up to it...

Quote: Original post by Oluseyi
Why not tell them their project is infeasible and negotiate it down to something much more realistic? I don't know what the arrangement is like at your school, but you might be able to work it out such that you continue to consult for them part-time after the summer. Get them to agree on a smaller core feature set - new routing system interfacing to old dispatch system via a bridge/adapter, and minimal AJAX UI to manage it - and implement that over the summer. Then, through the fall/winter semester(s), roll out new pieces incrementally.

The experience you'd gain would be incredible: negotiating, long-term development, incremental deployment, maintenance and updates...

Of course, it'd be better for them to just hire a full-time programmer who's not in college, but if they want to be cheap and you feel up to it...

Now, that's an idea. The general plan from the outset was that I work full time during summer and then continue working 8-10 hours a week after that. The problem is, since I'd be the only one on the project and my professional experience is limited (which is a less ego-crippling way to say "pretty much nonexistent,") I'm worried I'd make some retarded mistake early on that'd mess everything up down the line, doom the project, etc.

Quote: Original post by Anonymous P
Trying to satisfy the unreasonable expectations of people unqualified to recognize either incompetence or excellence in your field will teach you bitterness, but I doubt it'll teach you programming or anything else worth knowing (with the possible exception of 'never ever willingly accept a position as a fool's subordinate if you take pride in your work').

I agree that an environment with other competent technology savvy people would be a much better learning experience. Business people are not going to teach you how to program, but they can teach you a lot more then bitterness. Don't underestimate the value of learning to deal with incompetent, unqualified people with unreasonable expectations demanding the impossible, demanding it be done yesterday and demanding it be done for no money at all. There is an awful lot of that in the industry (and perhaps in most industries). Unless you are extremely lucky you will be dealing with it sooner rather than later and for longer and in greater quantities than any reasonable person would ever wish for. The worst part, as I see it, about the position is not the unreasonable description, but the isolation as the 'one' and only programmer.

It is also possible that they are in fact perfectly competent and simply uninformed or intentionally trying to weed out the unambitious. Oluseyi's advice is very good. If you propose a plan that is honest to the problem and to your skill level and they listen to you it is a big plus for them and for you. Don't worry too much about making mistakes -- it is much better to make the hard mistakes when you are still in school and have lots of options than when you are a professional who is supposed to know better.

To me, as it stands, the current project is wildly unrealistic. Projects like this require LOTS of planning and risk analysis. Especially if the future of the business is at stake.

If you do happen to take the job, my recommendation is to follow the waterfall software development life cycle or something similar. You want to have all of your specifications defined as best as possible before coming up with the software design. Then, you want to design your software to as much detail as possible. Since you have an existing system already, you can use that as a model to create specs and designs. If I were to take on this project, I'd probably spend ~60-70% of my time on specs and design, then transition over to the construction and development stage with a ~30-40% time split.

If you get a solid spec sheet and you get it signed off by the management, you pretty much have a contract for the deliverables which you're expected to provide. You shouldn't have many problems with miscommunication and misunderstood promises which could be a potential problem. Once you've got a complete design built to spec, you can give a much better estimate of the time and money it's going to take to develop the project. Based on your software blueprints, you'll have a much stronger position to gauge the needed man hours, cost and general software engineering concerns.

You can use this stuff to manage expectations and provide a reality check. If management balks at the price tag, it's easier to start crossing off features and put them off for further releases to save money and time.

Planning will make or break this project. The worst thing anyone in your position could do is to take the job and start writing code on day one.

Quote: Original post by Valderman
Now, that's an idea. The general plan from the outset was that I work full time during summer and then continue working 8-10 hours a week after that. The problem is, since I'd be the only one on the project and my professional experience is limited (which is a less ego-crippling way to say "pretty much nonexistent,") I'm worried I'd make some retarded mistake early on that'd mess everything up down the line, doom the project, etc.

It won't doom the project. It'll delay the project, since you'll have to undo it. We learn by making mistakes - and sometimes they're expensive. I just made a mistake on my current project. Actually, I made two: not correctly managing expectations early on such that I missed a critical deadline (lot of fretting, but really no big deal; I've caught up to the schedule and the final delivery is on target for this week), and failing to insist on a written specification. The latter was a much bigger problem because it led to feature creep and the notion that they can add new features whenever they felt like without adjusting the schedule. I've had to take a lot of shit as a consequence (like an SVP telling me he doesn't know if he can trust my schedule estimations - to which my only response is, "So? Who gives a fuck what you can "trust" besides you? Come write this code, bitch.")

Anyway... We learn by making mistakes. If they know that you're an apprentice-level developer and commit to having you as the sole developer, then they've effectively given you the right to learn on the job, and the value that will provide to your resume/portfolio if/when you successfully complete it will be tremendous. I say take the plunge, but only after having a thorough and candid discussion with the company.

Good luck!

The only time you should run away from a job offer is if there is a set task, for a set time period, for a set money that don't add up AND includes a negligence clause that makes you pay a penalty if it is not done in time. I seriously doubt that is the case with this job. Normally only high paid contract gigs have them.

No matter how structured the company is, there are idiots. There is no such thing as the 'perfect' environment, which is why there will always be challenges, so taking a job like this and learning about them early is most important. Just feel lucky you will have a chance to fully lead a paid project. There is a mental block many developers get in, they never get a chance to lead or design, and find themselves in a Junior/Follow position their whole career.

As others concur, you can get a lot of experience from any job that puts you in the role that this one sounds like will. Don't approach it as you will fail. Just try your best to follow basic software engineering practices, and learn what you can. Even if you run out of time, or they want to get someone else, at least you will leave the project in a state that others can continue, or bring others on to help.

Lastly, comes in the beauty of being in college. You have all your profs and peers to ask questions to. That is why they are there, and I am sure they will love to help give you directions.

The company has seriously underestimated the cost and time needed for custom software.

Consider their list:

Fully automated system to:
* accept and process continuous positional information
* detect specific alert conditions
* On an alert:
** send messages to cell phones
** send messages to alarm centers
** send messages to email

* Be visible through web scripted, carefully designed web-based front end
** "similar to Google Maps" (which was initially developed over the course of six months by a team of experienced engineers, and has now had four years of constant development by multiple large teams)
* plugin-based architecture for customer-provided functionality


Somehow, they also want this system to be maintainable by completely inexperienced beginners.


I would place that kind of project at around 30 FTE for the first production-ready version. That is, it would take a team of 15 experienced full-time workers about two years to implement.

If they only wanted the first half of the system, just the database and alert system, I would plan for around 10 FTE.


They want to hire you as an inexperienced person for 1/4 FTE. That is not even enough time to design a solid system to process and store the data.




I would tell the the recruiting agency that their project is badly scoped and should not be presented to students, pointing them to this conversation if necessary.