Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Then, if the code is written, the coder tests it to make sure that the basic functionality works, usually without completely checking the results, but making sure that it runs "end-to-end", and that it integrates with other modules of code that have already been written.
Then it is handed over to a Test Team, which SHOULD be fairly isolated from the development team, but which, in the case of OS, is probably not possible due to the small size of the organization. The Test Team, using the design documents, will have spent the development time in devising all the test cases needed to confirm that the app works as specified.
And here is the problem. Forget Alpha, and Beta, testing, because in a "shoestring" organization this process isn't going to be feasible, and probably the only testing carried out will be by the development team itself (hopefully using developers other than the one(s) responsible for generating the code) to confirm that, within the parameters of time and ability, it works somewhat as specified.
When they are "happy" that they've identified any major show-stoppers, they will pass it fit for distribution, and it will be put on the market for an unsuspecting audience that has been buoyed up by all the propaganda that has been flowing for months about just how wonderful the new offering is going to be.
Unhappily, many people will be disappointed.
Oh, and this dilemma isn't only suffered by small development teams. Teams up to, and including, the famed giant Microsoft, and even greater IT giant - IBM - have been caught out by faulty testing leading to disastrous results.
I'll just point out one notable problem from the past 30 or more years - code was written for NASA to control the descent of a space to ground lander where, because of a tiny misunderstanding, resulted in the lander descending in miles per hour instead of kilometers per hour, and when the lander smacked into the surface at a considerably higher speed than it was designed to do, resulting in a completely wrecked lander spreading itself across the surface of an astronomical body instead of landing safely and sending back the data that it had been designed to do. Now THAT'S an "Oops" moment.
/endrant
But your number 28M without any context and how it's distributed, literally means nothing, it's just a number,
Is this your total "income" ? Then something is definitely off in your city.
Or are those only your monthly expenses (primarily for services) ? Then it looks OK to me.
What is your tax income ?
What are your tax settings ?
Are you exporting any services ?
How are your service expenses distributed ? Which service is the most expensive one ?
For example:
I have a town with 400k inhabitants, a total income of ~6M/month, a service upkeep of 36M, tax income of 56M,... with taxes between 3% and 7%.
My most expensive services are garbage, healthcare and education, two of them are in the deep green area regarding coverage, so I definitely exaggerated a bit in buildings those buildings.