How is software developped in your company? 3

[Themuppeteer]

We all learn at school that in companies there are strickt guidlines fore software developpement,and that one should always first make a good analysis before startig to program etc.
But how is it really going on out there ? In the (big )company I work,only recent (about a year or so) people realized that analysis is necessary, no strickt guidelines to folow here yet,just 'make it work',the sooner the better.
How is it in your company?


Greetz,

The Muppeteer.

themuppeteer@hotmail.com

http://www.themuppeteer.tk

Don't eat yellow snow...

 

[garwain]

I'm in a small company, and it's pretty much a matter of get it working NOW, clean it up when you have some spare time...

this concept is in use for both our internal software and our website. basical the order of operations is

1) quick analysis
2) get the DB ready
3) draw up the interfase
4) throw in the logic
5) repeat 1-4 several times
6) clean up a bit of the coe from step 4
7) repeat the cycle

 

[xutopia]

Where I work this is what we would all like it to look like :

1) specs are drawn by functional people
2) developement is done by programmers
3) testing is done by functional
4) back to step 2 for every bug
5) launch

However it looks a little bit more like this :

1) specs are almost done
2) dev is done while the specs change because of deadlines
3) testing is done while correcting specification changes
4) back to step 1 because the client changed his mind
5) a programmer throws a fit or kills a functional
6) specs finally are clear or there are no more functional people to kill
7) back to step 2
8) launch

Hope this helps. Gary

http://www.xutopia.com

Haran

 

[Clarie]

My brother was finishing up his degree in programming when he came to work at my company for a summer. I delighted working with him because he was still academic enough to insist on some proper specs ahead of design and coding; however, that is not the way the business world works.

As stated before, it's "Get it working NOW" despite the proven fact that the 6 P's are still in effect: Proper Prior Planning Prevents Pitiful Performance.

I have also found that when you insist on build specs that are carefully thought out in their entirity before building anything, that either the client is lost right off the bat or they change their mind when they "see" how it works anyway.

Utopia is non-existant.

 

[Themuppeteer]

xutopia,
Do you really want other people to do the analysis ?
Do you think programmers should only do the programming?
I prefer beeing involved in the analyse also,as it is my first year in the 'big' world I would like to learn as much as possible,also analysis.
Over here,we have the software team on the one site,and the sales on the other site. Sales wants the program to be ready as soon as possible (they even have the habit of selling features before they are implemented or presented to the developpers,"its software,anything is possible&quot,while the programmers want a good analysis first (which taks time).
Specs should be frozen before the implementation begins,but I guess that is just a dream...
But when the program is quick and dirthy,and afterwards,it is not flexible due to bad design (due to lack of time),
the programmer wil be the one to blame since he should have done his job wright.
Greetz,

The Muppeteer.

themuppeteer@hotmail.com

http://www.themuppeteer.tk

Don't eat yellow snow...

 

[xutopia]

Themuppeter,

Do you want marketing people to do the programming?

I understand your concern and that is why I usually keep the functional people up to date with what can and cannot be done with existing technologies and how much time is needed for new things to be developped. They try not to sell features that have never been tried or hard to program. Thankfully most of our functionals understand what is needed to develop a program but that came at a price (communication).

I on my part don't like the functional's job. Here where I am they are the one that translate the desire of the clients (taking into account european and per country laws of financing and accounting) into something that I can understand (specs) so I can write clean code that my collegue programmers can understand.

I do have a voice and can communicate with functionals and the big bosses if I see that something could be done better, but no system is perfect and usually the best jobs are the ones where you can ask questions freely and tell people where something could be improved upon.

All in all you are right. Analysis shouldn't be solely up to a restricted group of people. If you are young and are still learning about how things get developped it is good for you to go from one group to another and see all aspects. But with time you will like specialising in one domain. Gary

http://www.xutopia.com

Haran

 

[Themuppeteer]

A system can be sold for lets say, a million dollar, and the marketing guy almost has the deal. All that has to be done to close the deal is an extra feature in the software, the marketing guy will say "no problem" and the deal will be closed. Then this guy mails to somebody of the software team and explains what happened. The analist-programmer has no choice but to find out how it is possible to implement the feature and do it as fast as possible. Thats the way it goes up here. Don't get me wrong, I like my job a lot,but when there is money involved,specs and priorities can change like the wind...
Greetz,

The Muppeteer.

themuppeteer@hotmail.com

http://www.themuppeteer.tk

Don't eat yellow snow...

 

[xutopia]

I know exactly how you feel. salespersons for a company should know better Gary

http://www.xutopia.com

Haran

 

[Themuppeteer]

Yes, but should they ? I mean,if the company is going to sell less because of some programmers who want to work by the book,it is not good for the programmers either. Are we in the position to say 'no' to certain demands and if so,is it smart to do so? I guess not... Money rules the world.
Greetz,

The Muppeteer.

themuppeteer@hotmail.com

http://www.themuppeteer.tk

Don't eat yellow snow...

 

[Craig0201]

Muppeteer,

The answer is you work for the business. Your job ultimately isn't to write code but to maximise profit via either sales or cost reduction (or in my case minimise spend as we have no income).

If the business can make more money by a sale with added functionality, they will (and SHOULD!) sell the functionality. What should be made clear at the sale is that it may take time but at no point should coders run the business.

Craig

 

[garwain]

We should not have the power to say "NO WAY! it's impossible", however the programmers should at least be consulted. In the million dollare example, the sales tack on one more feature that will finalize the deal, but without consulting the programmers, they could be costing the company money. If that feature requires us to re-evaluate our design, scrap half the model we came up with and require 5 additional junior programmers on the project and sales doesn't consider the additional time+labor on the project, it might have been better to have not done the project.

little example
project A $1,000,000 requires 3 months + 1 month due to additional feature
projects B, C and D 1 month each put on hold to do project A

originally B,C and D were put on hold because A was would make an additional $100,000 in the same time period.

now we take an additional month and project E was also finalized for $300,000 estimated to take 1 month but put on hold because we have to finish A first...

simple math shows that now because of that additional feature that sales said "sure we can do it", we are now loosing $200,000, plus the client for project A is mad about it taking the extra month, D has realized that the can get their project completed within 1 month by a competitor for an extra $50,000

wow, now we have lost $500,000 because sales went and agreed without consulting the programmers who are the only ones who could have put up a flag and said "wait a minute, this is going to require extra time + resources."

I wish I could work with those numbers in real life, but that was just running with the example given. I have seen this happen on a smaller scale though, and management, and shareholders are never happy if they loose even a penny out of their profits!

 

[Themuppeteer]

Thnx a lot guys!
one small remark to garwain:
I don't know how it is done over there,but over here
if an extra spec has come up, the man power on the project stays the same, and also the deadlines stay the same...
Those big numbers come from the fact we write software for expensive machines,and the purpose of the software is to sell more machines. Greetz,

The Muppeteer.

themuppeteer@hotmail.com

http://www.themuppeteer.tk

Don't eat yellow snow...

 

[Chance1234]

Project Manager says "Make it Work NOW!"

programmer makes it looks like it works now ;-)

User raises Bug

programmer sticks pretty picture on form , tells user bug is
undocumented feature

User Smiles at picture content with Bug

Project Manager not happy with bug goes to programmer

Programmer says nothing he can do, its your fault for wanting to develop on a microsoft platform

Project manager uses some management slang like "Non conformance issure to explain bug to CLient"

Programmer finds he has a spare 5 minutes and fixes bug, waits for everyone to leave the office goes down pub comes back to office at midnight and sends e-mail to project manager saying "Ive stayed all night and by a miracle i fixed the bug" and submits overtime claim

User happy as has pretty pictures and no bug!
Client Happy as product works
Project manager happy as project in on time and delivered
Programer happy as got overtiem for doing nothing


down the line ....

Client and user raise more bugs, in the distant can be heard "Project Phase 2 ....", "New Car....", etc etc etc


Chance

http://www.5ylac.s5.com

http://www.wrap.4t.com

http://WWW.5YLAC.S5.COM

 

[garwain]

The Muppeteer:

If the deadline stays the same, and the staffing doesn't change, then that would just add to the potential loss. Scraps half the example I gave, but now because you have more work, and by the time the programmers have re-analysed the project with the new feature, they will have to cut corners to meet the deadline... This will result in the client getting software that hasn't been fully tested, and code that has been slapped together, making it harder to maintain. the programmers will also be putting in a lot of extra overtime which is going to be costing the company...

Sales NEED to communicate with the programmers in order to know how adding this feature will affect the rest of the project. Then the can go back and tell the client "If we were to implement that, we would a little more time and it would cost an extra $$$$ so that we can guarantee that the product is of the highest quality. If you don't allow for the increase, you'll regret it later because it'll cost more to maintain the software, and several bugs will likely slip through."

That is the reason that where I am, the programmers are typically the ones that set the price and deadline on the projects.

 

[Themuppeteer]

Well, overtime isn't payed over here. And if you don't catch your deadline,no bonus to... Sales should talk to the programmers, but what really happens is this:
The customer asks "can your system do this:blablabla"
sales guy wants to sell and says :"of course it can" (knowing the programmers wont let him down)
customer says ok,we buy.
sales guy says: programmer implement.

Greetz,

The Muppeteer.

themuppeteer@hotmail.com

http://www.themuppeteer.tk

Don't eat yellow snow...

 

[PTCruiserII]

My answer is - get rid of sales guys and get ex-programmers to take over sales. Then you have real power in any negotiations because the programmer/sales person knows what promises he/she can keep and which ones he can't. Get salesmen jobs working at WALMART.

 

[NevG]

I agree with alot of points up there about he way it would ideally be done and the way it has to be done. I work for a very small company, in fact I am the only employee so like M Ben I have to hcange hats every timethe phone rings. Im sales,functional, programmer,market rep all in one. Thats hard to live with and I sure as heck dont get time to do specs.

Thats my entry in this interesting debate.....

 

[VBmim]

I work in a small company (not it-business) and here it works like this:

1)Programmer writes a small program that works well and has some good programming (with a few bugs, I admit )
2)people want more features in program (lots more)
3)Programmer says she'll have to rewrite most of the application if she want's to do it right (I mean: good programming)
4)Manager says there is no time, just work around it and write something that will work tomorrow

Reapeat steps 2, 3 and 4 untill you have a program with useless code, uncountable bugs, and everything you can imagine with bad programming...

I think I am not the only one in this situation...

oh well..... sometimes it can be funny ;-)

 

[Themuppeteer]

If you don't have a good design,what usually is the case when you start small and have to expand all the time, you'll end up in trouble after a while, cause new features will keep on coming and your model won't allow them anymore. Then you'll be forced to remake the whole application...
I have the luck that they gave us time to make a good model,so it an take some "mood swings" without losing its flexibility and expandability (if that is correct english ), still, mood swings of sales are a pain in the... X-) Greetz,

The Muppeteer.

themuppeteer@hotmail.com

http://www.themuppeteer.tk

Don't eat yellow snow...