Ask Dbstalk: Question About Sw Releases

[Eagles]

Just curious as to how Dish determines when it's OK to release an upgrade, as it applies to the 921. As you know we have seen many target dates come and go. From what I understand, the Tech Chat guys gave a date if 11/18 or 11/19 for L189. When they give these dates weeks and sometimes months out is it based on the fact that they already have a somewhat stable version with some minor bugs up and running, and they are assuming it will take X amount of time to get the bugs out? Or in the case of the Tech Chat stated target date, do they already have a stable version which must now undergo an intense beta period prior to public release? Or is the whole thing just a bunch of best guesses?

[boylehome]

and they are assuming it will take X amount of time to get the bugs out? Or in the case of the Tech Chat stated target date, do they already have a stable version which must now undergo an intense beta period prior to public release? Or is the whole thing just a bunch of best guesses?
You have asked the $10,000,000 question. Out of all the released that I received, there still exist bugs (what's with that? :mad: ). This is my assumption based on past release practices: I guess that the, "team" decides to release on a specific date once they, "team" thinks they have all the problems fixed. E* most likely puts pressure on them to get their product fixed quickly, so the, team" throws them a bone (or release date) :) . It seems that they are still or were encountering continued problems with L189 which has delayed previously projected release date. The change of the release date may also be attributed to feedback from the beta testers who are encountering problems with the beta version. The L188 was more of an, "emergency fix" release (cuz it sure still got da bugs) to satisfy E*, the customer (or whoever) :rolleyes: In the end I think that that your final conclusion, "Or is the whole thing just a bunch of best guesses?" is more on point. According to the X-File team, the truth is out there. :eek2:

[SimpleSimon]

Remember - there's simply no way to address all the bugs all at once.

While I am far from a fan of the 921 software developers (or at least the designers), one of the biggest mistakes that is made in the software industry is trying to do too much too fast, and/or adding a bunch of people to a project this far in.

Generally speaking, the 921 can be broken down into several pieces, such as OTA, satellite, program guide, human interface, database/file management, core operating system, etc.

Trying to put more than around 3 people into actual coding in each of those areas will be counter-productive. You can have a lot more 'outside' doing research, testing, etc., but the number of coders has to be kept small.

Now, that being said, it's entirely possible that ARE too few, or mis-organized, teams working the 921. For example, we haven't seen much in the human interface area - maybe those guys are shared with program guide needs? Just speculating.

[KKlare]

one of the biggest mistakes that is made in the software industry is trying to do too much too fast, and/or adding a bunch of people to a project this far in.

Trying to put more than around 3 people into actual coding in each of those areas will be counter-productive. You can have a lot more 'outside' doing research, testing, etc., but the number of coders has to be kept small.


You might be interested in the "Mythical Man-Month" by the leader of the IBM 360 computer project, circa 1970. He describes where adding people actually slows the development. Oh, for a few good men.

[jsanders]

The other one that can really effect things both positive and negative are the managers for a project. Like programmers, you don't need too many. The manager is like the conductor of an orchestra. He can make horrible, screeching noise, or beautiful music!

An example, I know a manager where I work (different group) that doesn't like #ifdefs for the the different products his group produces. So, he decided that there should be no CVS system, and no #ifdefs for each product. Instead, he has an almost identical code base for each project, without any revisions. Each time he is at a spot he likes, he tars the source into an archive. Now, when someone makes a change to the core code, he has to go and untar ten different archives and make the same change everywhere, and then re-tar them all back! I'm glad I don't work for him....

I completely agree with you on the programmers, each subset should only have one to three people. Those people need to work well with each other, they should be very aware of what each other is doing. That gets much harder to do when you add too many people!

[SimpleSimon]

You might be interested in the "Mythical Man-Month" by the leader of the IBM 360 computer project, circa 1970. He describes where adding people actually slows the development. Oh, for a few good men.Yup - that's where I first learned it as a punk kid. ;)

It's a shame that so many others haven't learned those lessons over 30 years later. :(

[Frank Z]

Mark knows, but he can't tell us!! ;)

[kstevens]

Yup - that's where I first learned it as a punk kid. ;)

It's a shame that so many others haven't learned those lessons over 30 years later. :(

Believe it or not you can add people to a project and still accomplish it faster :-). It has everything to do with the project lead and how accommonable the code is to being broken down into pieces. If you try to break it down too far the the programmers tend to stomp all over each other. But a properly compartmentalized project will speed along with the appropriate number of programmers.


Ken

[Mike D-CO5]

Believe it or not you can add people to a project and still accomplish it faster :-). It has everything to do with the project lead and how accommonable the code is to being broken down into pieces. If you try to break it down too far the the programmers tend to stomp all over each other. But a properly compartmentalized project will speed along with the appropriate number of programmers.


Ken
I think what we have is a team where the right hand doesn't know what the left hand is doing. This is commanly known as a cluster f*ck. I should know , I work for the state of Texas prison system where this is their main motto and mission statement. :sure:

[kstevens]

I think what we have is a team where the right hand doesn't know what the left hand is doing. This is commanly known as a cluster f*ck. I should know , I work for the state of Texas prison system where this is their main motto and mission statement. :sure:

If that is the case, then the project lead is at fault. It is his/her responsibility to see that all programs are working in harmony.


Ken

[SimpleSimon]

And that's pretty much what I've been saying.

However, I DO argue that adding people late is generally non-productive due to the time it takes to bring the newbie up to speed. An example exception for this case MIGHT be bringing on someone from the 721 team. Another would be to bring in people to work on non-critical bugs in code areas that can be isolated, where there were no deadlines to speak of.

[Mark Lamutt]

Yeah, I do know, and am not going to comment beyond saying some of the ideas flung out in this thread are accurate, and some aren't.

[Frank Z]

I must be psychic! :lol: