Is This Normal Development Procedure?

Question

First a little about myself. I am not an experienced software engineer, architect or developer. I have done mostly small ASP and ASP.NET projects in C# for the last 5 years. I am pretty good with HTML and JavaScript. These projects were done when I had free time from my other duties which were not related to software development. I have now been moved into a software developer position. The company I work for is not a software development firm.

I am now working on a Silverlight LOB application with WCF and Entity Framework. I have been given little specifications for this project, just the 'make an application like X, only simpler so we don't have to pay for it', my boss doesn't check on my progress as often as I think he should, the project manager(a co-worker) will stop by now and then but we never discuss the specs, architecture, UI or business rules. I am mostly just asked when I think it will be done. I have had to learn Silverlight, WCF and Entity Framework to work on this project which is not a problem as I really enjoy working with these technologies. The problem is I am the only one in the company that knows anything about these and have no mentor/boss to discuss the problems and how they could be solved. I have been able to seek out one interested party in the company that has at least given me a list of some of the requirements.

I can't believe this is how software development should be done. I think the project managers should offer guidance and keep a closer eye on what is being done to prevent going in the wrong direction(but how can they in my situation since the don't know the technologies!).

Should I feel this way or am I way off base?

Thanks for listening.

Answer 1

Your project will likely fail from your boss point of view. Because i'm sure you developing program not suitable for him. But you don't feel guilty. It's your boss' pain.('because you are good programmer). Sorry for so dark post :-).

Answer 2

What you describe is certainty not optimal, but it's extremely common, particularly in smaller shops. Some people find it rewarding to work in that kind of environment. It's not what the software engineering books teach, but that's why there are so many software engineering books.

If you want to continue working in this environment, you're going to have to supply all the discipline you rightly recognize as missing yourself. Write up a spec. Build a schedule. Share these with your management. Hold yourself to deadlines.

Share your concerns with your management; don't be shy about that. Chances are, they recognize the situation. Your boss doesn't check your progress? Publish your progress to him. Show him where you need to get to, how far along you are, and what's blocking you.

It'll be chaotic, no doubt, but you'll learn a lot.

Answer 3

Every organization is different. If they are operating in this capacity then you should adapt and make the best of the situation. It's either happening because that's how things are done and they are aware of it, or they don't know the wiser or don't want to invest to improve the process of delivering strategic/tactical projects.

In a perfect world everyone would have a robust Quality Methodology in place which would provide a framework for Project delivery and systems implementation. It's just not a reality.

Here are some tips to help you operate more effectively:

• Identify your sponsors (the people who own the product) and determine the high level benefits and driving objectives of the business problem they seek to solve
• Identify your stakeholders (who has influence and who has interest) and get them to communicate their needs as much as possible
• Involve both sponsors and stakeholders in the process as much as possible or as much as they want
• Capture what requirements you can from them through written form (email)
• Provide opportunities for them to gain visibility into the delivery and to provide feedback

Answer 4

The role of the project manager is not to know the technology, but they definitely should have a finger on the pulse of the project, so to speak. The real project management job is not to control the project, but rather to enable it. Either way, from your description, looks like yours isn't doing such a great job at it.

The other extreme is a process-heavy organization where meetings and committees decide everything, and all the real communication, if it exists at all, happens through side channels.

The ideal world lies somewhere in between.

Your project manager should not be too concerned with how you're doing things. Since they have no qualifications, the best they can do is connect you with someone who does. When they can't verify that you're building the thing right, they should at the very least ensure you're building the right thing. Even if it's for internal use, you still have a customer, and no communication with the customer spells bad news to me. :)

If your PM is not concerned about the issue, you could try to do something yourself. For example, ask the PM to connect you with a would-be end user of the application. Extract bits of your application and give them to the user to play with -- just make sure the bits you give them don't look or feel too finished.

If you can't change things, take this as a learning experience. Make sure next time you're up for a project, you know the things that went wrong last time, and try to mitigate them from the start.

And finally, if your bosses tell you this is a "more agile way" of working, punch them in the face. Agile is, or should be, synonymous with discipline, not complete lack thereof.

Good luck!

Answer 5

It is a hard situation. Only you can really determine the best way to proceed. However, I do think that the concern with the schedule and concurrent lack of documentation (requirements, expectations, use-case scenario documentation, etc) is a train-wreck waiting to happen. Even the sharpest and most experienced dev-teams suffer from the same problems.

The "when will it be done?" questions are best mitigated by regularly providing small partially functional builds that you can use to get useful information out of the moving target that is your customer. It is amazing how much communication can occur when somebody (your boss/customer/end-user) can actually "play with" something in front of them and reconsider what they really want.