The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Coding vs. Writing

We have small software company. Now developing client-server software for production accounting of electronic plant.

I’m making screen-by-screen spec, always writing down solutions we made talking with 2 coders of client side and 1 user guide writer. We also have 1 architect of server interface who working independently now.

I’m writing spec like that:
1) Finding problem of system architecture/GUI/smth. else;
2) Creating briefing with coders;
3) We have brainstorming;
4) I’m making decision;
5) Writing decision in spec;
6) Publishing spec on internal web-page.

It works fine but the bad thing is: coders don’t want to write down technical spec of their code and nobody of them wants to be responsible for architecture. They’re making all decisions on code architecture simply talking with each other. That’s why we
1) can’t scale our team (for example, hire more programmers, because they will need at least 2-3 months to understand the “coding vector”, and I’m afraid new guys will divert old programmers a lot – time is critical);
2) can’t make any useful plan (only fictive “monthly” plan for customer);
3) I can’t see the complexity of code and can’t effectively cut features myself (every time I’m asking about cutting features, programmers telling it’s OK, they will do it in time. Um… hope they’re right!). 

I see we need professional software architect (or lead programmer), but still can’t hire him because of low budget.

We have low experience in software management. Can you advice some solution?
Andrew Shkuropiy Send private email
Sunday, April 16, 2006
 
 
> I see we need professional software architect
> (or lead programmer), but still can’t hire him because
> of low budget.

You mean you need a non-productive person who doesn't know more than anyone else yet gets to tell other people what to do?

You haven't said the product sux so your people must be competent in that regard. The issue is how to bring on more people.

Often people don't right down architecture because it is so impossible a task. It so big and so complex what do you write?

You may want to interview them and extract the arcitecture .

This will only help so much. It wouldn't matter for a new person anyway because the architecture won't tell them 20%  of what they need to know.

Bring on people slow. Have them do small things. They'll work with the other programmers and they'll pick it up. That's how people learn.

That doesn't mean you don't have good practices like TDD, builds, etc. But expecting people to come up fast because of comprehensive architecture doc isn't very realistic.
son of parnas
Sunday, April 16, 2006
 
 
Do what everyone else does on a restricted budget - copy the basic functionality of a similar product and build your client's specific requirements on top of that.
Brutally Honest
Sunday, April 16, 2006
 
 
"...I’m making screen-by-screen spec, always writing down solutions we made..."

It sounds like you're already doing what a software architect does; your only problem is that you don't have the experience or the authority to do things like cut features.

If this is something you don't want to do, then you have a serious problem, and given your budget constraints, you may have to either do it anyway, or look for a different position.

If this is something you do want to do, you need to take all of the documentation you've written and go talk to your manager or your boss. Let him decide if what you're doing is acceptable (he's willing to take the risk) or if you need more power and training.
TheDavid
Monday, April 17, 2006
 
 
Perhaps you need to have more influence over your weekly changes to the application.

You have a list of things to be done, tell em which ones you want by the end of the week, and then the ones that are due the week after.  You should be able to know if they can do them in a week, ask the programmers for their timings if you don't have enough of the know.

this way, if they run out of time, all the critical bits will at least be done, and the less important ones as you see them will be on the plan for the next release.

Friday, April 21, 2006
 
 
I think its a bit late to respond on this but ...:

Few things :

1. Ask your Coders to put lots of comments in their code. Ask them to follow a a pattern in the comments.There are tools that will create documentation from code comments.

2. Ask them to review each other's code every day.

3.Once this process is in place, a new guy can come and get the screens from you, look at the code and does not have to disturb every one else.[atleast as time progresses.]

Ask your coders to make reusable pieces of code and reward/Encourage them for every reusable piece that they write :This way, they will make sure that others understand what they wrote and your job gets easier.

HTH
Sri Send private email
Thursday, May 04, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz