death march 7

[mamu]

hi fellow death marchers...

i'm working on a terrible project. 'finished my studies 8 month ago (worked in web development, as a student for 1 1/2 year, then full paid, for about 1 year, finishing my cs-studies); 3 month ago i signed a contract to work within a team to create a new (portable, c++) gui for an propriatary system.

during employment interview i thought, i will be part of the team that's developing the new gui, now i've learned that i AM the team. there's only a lousy specification, various/different interests in what this software should/will do.

Until now, i produced about 10,000 lines of (lousy) code (of which i dumped 5,000), just to get some features running. Got a communication/api - lib of 5,000 lines, an example app of 7,000 lines, with less than 1% comments, half time i'm trying to figure out what thes api does...

What would you do, trying to get out of this mess, or try to get an meeting to get this thing straight? (just for your info: after every meeting, i was puzzled more than before, boss says this, manager that, api-author said another thing...)

thanx in advance, martin

 

[iSeriesCodePoet]

I would "take charge" a bit and in the meeting speak up. Say "I am completely confused here. What is it that I am supposed to do here?", or something like that. In some case they might be thowing out ideas. Make them tell you what is it that you are supposed to do. And make sure that they are all telling you the same thing, once that happens, then writting your code should be easier. Look up documentation on your APIs, if you are confused, ask questions. This should make you look even better in the eyes of your employer. Most of my learning has been done through asking questions in forums and email groups. Then ask the occasional question of my co-workers.

To qualify myself, I have been in the business for a year myself. Mike Wills
RPG Programmer (but learning Java)

"I am bad at math because God forgot to include math.h into my program!"

 

[carp]

1. If you are in any position to demand anything, demand a requirements document. If they can't define what they want, then your odds of producing it are greatly reduced.

2. Try to find out who developed the APIs, and then start asking them questions (although it may be too late for this - we've run into the same problem recently. The person who did the APIs is long gone and forgotten!).

You could bail out, but just FYI - you are not in a unique situation. The lack of clearly defined requirements is symptomatic of management that (a) doesn't understand IT and (b) doesn't really know what it wants. Both are epidemic these days. This makes it imperative for you to develop listening skills and a good understanding of your employer's business (as well as what the managers are trying to do). That way, you can help fill in the gaps when they're trying to articulate what they want. By asking simple, careful questions (leading), paraphrasing what they're saying (feedback), and making useful suggestions, you can become a highly-valued resource while making your job easier. As for enlightening managers technically, there's only so much you can hope for if they're not already technically astute; analogies are very helpful.

Good luck, and know that many of us feel your pain!

 

[pivan]

carp is absolutely correct.

I would further suggest that in abscence of requirements document, you create when yourself, review it and get sign off.

To bring some sanity to your situation you may have to wear the hat of a business analyst and make sure you have the requirements nailed down and everyone's buy in obtained otherwise there is really no point in beginning coding.

We have done that here, since we do not have a business analyst the developes create their own requirements spec. based on input from sales and CTO. Then Use cases, then coding etc. While it takes longer on the front end, we have increased time to market by 200%.

Gosh ..good luck and hang in there....man..all of us have been there.

pivan If not now, when?
If not here, where?
If not us, who?

Just do it!!

 

[carp]

As a follow-on, I reread your original post and was struck by "I AM the team!". I've gone through this drill too. One thing you need to bear in mind (if you don't already) is that by "being" the team, you are also a de facto manager. Consequently, you are on a somewhat equal footing with the other managers - although they may not believe it. But one of the responsibilities of a good manager is looking out for his/her people. This becomes especially critical in your situation, because you ARE your people. If you would demand clearly defined requirements and timelines for subordinates, then you should do the same for yourself. Otherwise, you WILL be doomed to failure. Also, if you are dealing with indecisive or ignorant managers (as I often have), you will be amazed at how grateful they will be and how much easier your life will be if YOU tell THEM what you are going to do and when you will do it. While diplomacy is absolutely essential here, I have found that people are often happier if you draw some lines and limits. They may not like what you have to say, but they tend to respect you more and are glad to have something definite to hang their hats on.

If you need to explain poorly documented APIs, you might try something like this:

"Trying to code to a poorly documented API is like trying to set up your satellite TV system and finding out the instructions are written in Japanese. Eventually, you'll figure it out, but it's going to take a while!".

 

[mamu]

koldark, carp, pivan, thanx! i really needed a little backup.

pivan, thanx for your advice. i've been talking to some it-managers (friends, or people in companies i worked before), but no one believes a good requirement gathering will increase speed of development (i still do!). as a student, i've done some projects for siemens, it's pure bureaucracy, they had been discussing the layout of names (so called resp. publishers of intranet-pages) for hours, but changed 'my' EMR of the database (15 tables, sceduling, huge e-mail workflow) within seconds. any chance to prevent 'managment' from doing this?

after this situation i demanded a good 'requirement gathering' and use of tools like uml/erm/ooa for such non-trivial projects, but the only thing i received was the advice 'not to be that naive, it's software development, we have to change the requirements during development, that's what will keep us on market'. well, fact is, the company went bancrupt soon after (siemens said, the applications were 'random products' (in german language: 'zufallsprodukte', it's try'n error programming, no trainings for programmers, just hacking and self study...).

well, another question, what do i have to do, if i want to get REALLY DEEP into UML/OOA, i'm currently reading books
of booch, de marco, etc. is there a good way to get experience with uml (something like 'off' the job training). in the company i'm working now, there's no chance to 'demand' the usage of these tools, they only want to see 'progress,progress,progress'... (good thing, despite all odds, i'm 1 week in front of my personal project-scedule, ;-)

well that's enough whining for today, back to work...

THANX A LOT TO ALL OF YOU!

-- martin

 

[carp]

I have found that when trying to learn a new technique, language, etc, the hardest part is finding a scenario to use the technique on (you can only do "air traffic controller" or "checkbook balancer" so many times!).

If you want to learn UML, you might try modeling whatever you're doing at work. That way, not only do you have something to apply it to, but you have something for "show and tell" at work. This serves to show others the value of the technique and acts as an entree to more order in your professional life. NOBODY is likely to see value in the concept unless they can see the concept at work!

Finally, I would submit that the people who think there is no benefit to defining requirements are the ones who are naive! How many times do they do things in their personal life without a requirements definition? Do they just get in their car and drive around, hoping that their needs will be met? Probably not! If they're hungry, they'll define their requirement (eliminate hunger), formulate a plan to satisfy that requirement (go to restaurant for dinner), get in their car and take the most efficient route to the selected restaurant. If they're remodeling their house, they'll go through a similar process. Of COURSE you need requirements defined! How else will you know which direction to go or when you have arrived at your destination?

"no one believes a good requirement gathering will increase speed of development" indicates to me that you are dealing with some of the stupidest people in business. Unfortunately, they are not rare!

 

[Smack]

Martin, I would strongly reccomend taking the Franklin - Covey project management class, it is only two days, but you will get alot out of it. It is well worth the investment of time/money. Almost everything you describe is covered. If you can't make the class, you might want to check out "To do, Doing, Done" by Snead/Wycoff.
Good luck!
-Smack

 

[mamu]

carp, and all others, thanx, i'll DO my best!

wish you all a peacful weekend...

 

[pl12987]

Here's one technique that I think could help you down the road:

I agree you should do all you can to get a requirements document. But the statement in the example about changing it later is correct too, because PEOPLE DON'T KNOW WHAT THEY WANT UNTIL THEY SEE IT.

So, once you have a concept, do a rough GUI FIRST, with just enough code to make the functions appear to work...in other words, a prototype demo. It should look and work like the real thing, except perhaps buttons or forms could generate pre-scripted results instead of doing an actual lookup.

Show it as a working model and ask for comments. Don't be defensive, just listen. Then you will find out what they really want, and not have to throw out a month's worth of code.

Good luck.

 

[BigMag]

There's a rule in software development.

"Good software is always written twice"

So don't worry, get rid of the other 5000 lines and start over! (If possible)

Greetings,

M.
BigMag, The Netherlands.
someone@euronet.nl (no kidding!)

 

[mamu]

pl12987,

>PEOPLE DON'T KNOW WHAT THEY WANT UNTIL THEY SEE IT.

well, that's excatly what i'v learned from working with SIEMENS.

BigMag,

>So don't worry, get rid of the other 5000 lines and start >over! (If possible)

well, not possible. i'd be fired within seconds. (it's not for the fun, it's for the money, and i need money!)

An anecdote, i've heard 2 days ago: There was a guy in this company who did a similar thing like me (a gui, not portable between windows/linux), he also had no real spec, no real guidlines, just like me he only had deadlines. And guess what, he had been fired because the app was buggy and not well designed.

I'll keep you informed about changes in my current situation...

ANOTHER QUESTION, does anyone of you know Tom DeMarco. I mean, do you know him personally, i'd like to get in contact with him... ('read a couple of books, perfect readings)

btw. you guys are all a great help too! i won't miss tek-tips, it's one of the best sites on the web...

thanks a lot to all of you, martin

 

[carp]

re: "People don't know what they want until they see it."

The flip side of this is people don't know what they DON'T want until they see it. This is what makes prototyping such a great tool - ESPECIALLY when your customer can't (or won't) articulate what they want. You take your best guess, set their expectations as well as you can, particularly letting them know this is a PROTOTYPE (first cut, best guess, conceptual model, or whatever term will get the idea across to them), and then do a show and tell. They'll let you know right away what's right and what's wrong. Document these reactions and then get them to sign off on what you've documented. What you'll have might not be a formal requirements document, but it will be better than nothing. If you've modularized your design well, you can just cut out the parts that they DIDN'T like (but save them - I've had to go full circle more than once! For heavens sake, DON'T throw away 5000 lines of code unless it was junk to begin with!), keep what they DID like, and start bolting on what they wanted but you didn't already have in place. Eventually, you'll have Release 1.0.

Godspeed and fair seas!

 

[LoaferMan]

Have you ever heard of a "Charter" document?
It contains the following things.

Who are the key decision makers?
Who is responsible for what on a project?
How will we know we will have succeeded?
What we are trying to accomplish?
What is the scope of the project?
What is the timeline of the project?
What is the purpose of the project?
Who reports to who on the project?
What will be the rewards when are succeed?

This document is put into place, examined, and signed by all responsible parties, BEFORE any programming, specifications, or prototyping takes place. That way, everyone is working with the same playbook.

For example, when you found out you were the Entire team, you could have referred back to the "Charter" where it said the team would consist of four people and pointed out that you will be happy to work on the project, but it will obviously take longer, and it will be obvious why.

People often conveniently "forget" what they asked or promised. A "Charter" keeps everybody honest. LoaferMan - There is no practice life. This is it. (Billy Crockett)

 

[elizabeth]

I agree that the problems you are talking about reflect lack of qualify in project management. Project Management is now one of the fastest-growing professions. There is a forum on this site specifically for Project Management. I think you will find a lot of useful info there. The Charter that LoaferMan mentions is normally the first step in a project, as it clarifies everyone's understanding. Usually communication is the main problem in any project. It's never too late to write a Charter! Once you write it based on your own best guesses, you meet with your management and stakeholders and modify it until you have consensus. Then drag it to every meeting you have because if it's everyone's first Charter, it will continue to evolve. Good luck...

 

[mamu]

Hi, nearly 4 years ago i started this thread.

In November 2001 they fired me. What made me smile was, that they hired up to fife programmers to finish the project. It took them about 3 years. My (single pgorammer) timeline was set to 6-9 month.

Looking back at 2001, i'd like to thank you all for your tips, learned much since then, have to learn more.

esp. these advices helped me a lot!

> "To do, Doing, Done" by Snead/Wycoff. (Smack)

Smack, thanks! it worked, my desk's clean (most of the time)

> "Good software is always written twice" (BigMag)

BigMag, thanks! I'll did this a couple of times (without my manager knowing it)

> "Charter" document (LoaferMan)

LoaferMan, thanks! This is a good idea, worked in a company that did some charter documents and some kind of valuable spec's.

Bye Guys!!!!

-- martin

"No matter how much you know today, you'll have to know more tomorrow."

 

[chiph]

Wow, this is an old thread!

I'm glad that people here were able to help you out. It's unfortunate that you had to learn that sometimes it's better to walk away. It happens all too often in our industry.

Hopefully you got a better job afterwards.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first