Software Astrology

• Days of possible critical problems: 9, 18, 26
• Days of unfortunate computation: 4, 13, 22, 31
• Days of good enough software behaviour: 6, 15, 24
• Fault-free days: 1, 11, 20, 29

- Dmitry Vostokov @ SoftwareAstrology.com -

• Days of possible critical problems: 3, 11, 20, 30
• Days of unfortunate computation: 7, 16, 25
• Days of good enough software behaviour: 9, 18, 27
• Fault-free days: 5, 14, 23

- Dmitry Vostokov @ SoftwareAstrology.com -

The Day of Heap Expansion

Modules, products or systems built on December 15 compute big. Their expansive algorithms run free into wilderness. Few limitations exist for their code because it knows how OS works, but once they are on top of the list they don’t know how to keep staying there. December 15 components need to learn how to be satisfied at various resource levels and security restrictions. They do their best in computation when they care about other modules and do not interfere with other processes and threads. Products built on December 15 are liked by many customers. When they see them compute they feel good with their easy and open interfaces. December 15 modules from financial products are open to exploits and have vulnerabilities discovered with depends.exe. They are usually not concerned with such matters and can be sometimes computationally fatalistic, destined to loose data but can restart instead of hanging on exception. Thoroughly compute with all possible checks and then move to another step of their algorithm is the safest thing for them. Modules, products or systems built on December 15 may overestimate resources available for them and overlook deterioration symptoms so various external checks are recommended during their normal computational life span. Training is mandatory for their troubleshooters. Data restrictions are not necessary unless insisted by a security engineer. Running on open platforms is advised for December 15 systems.

DLL, SYS and EXE born on this date:

usrxcptn.dll Fri Dec 15 08:33:42 2006
PCIWNT.SYS   Tue Dec 15 19:46:09 1998
AegisP.sys   Thu Dec 15 10:31:20 2005
srv.sys      Mon Dec 15 21:42:35 2008


Weaknesses: Unrealistic expectations of available resources. Blind messaging.

Strengths: Well-linked modules. Cheerful sounds.

Advice: Don’t have a condescending attitude towards customers. Learn to deal with security constraints. Remember that heap can contract too.

- Dmitry Vostokov @ SoftwareAstrology.com -

• Days of possible critical problems: 5, 14, 24
• Days of unfortunate computation: 10, 20, 27
• Days of good enough software behaviour: 3, 11, 22, 25, 29
• Fault-free days: 8, 18, 25

- Dmitry Vostokov @ SoftwareAstrology.com -

• Days of possible critical problems: 4, 23, 31
• Days of unfortunate computation: 8, 19, 26
• Days of good enough software behaviour: 6, 24
• Fault-free days: 2, 10, 21, 29

- Dmitry Vostokov @ SoftwareAstrology.com -

• Days of possible critical problems: 3, 11, 21, 30
• Days of unfortunate computation: 7, 17, 26
• Days of good enough software behaviour: 19, 28
• Fault-free days: 5, 14, 24

- Dmitry Vostokov @ SoftwareAstrology.com -

• Days of possible critical problems: 7, 15, 25
• Days of unfortunate computation: 1, 11, 20, 29
• Days of good enough software behaviour: 3, 13, 23
• Fault-free days: 9, 18, 27

- Dmitry Vostokov @ SoftwareAstrology.com -

The Day of Software Exhibition

Modules, products or systems built on December 14 impress potential buyers at software exhibitions viewing their GUI but they rarely open their internals to show what they really are inside and what they are really computing. December 14 components have very complicated code and complex architecture. Many of their computations are bizarre. Their code is not ordinary, is self-aware and often confronts their parent processes and computational authorities. Sometimes it is not even possible to fit them into a predefined algorithm and even if it works initially later it causes enormous problems, for example, outraging a customer. However the good side to their challenging behaviour is that they are catalysts for software change. Modules, products or systems built on December 14 should be very careful with accidental violations. Their code might not be understood or they themselves might not understand their environment and that could result in their withdrawal from computation.

DLL, SYS and EXE born on this date:

ialmrnt5.dll Wed Dec 14 20:47:26 2005
ialmdnt5.dll Wed Dec 14 20:47:19 2005
ialmdev5.DLL Wed Dec 14 20:47:09 2005
ialmdd5.DLL  Wed Dec 14 20:54:40 2005
ialmnt5.sys  Wed Dec 14 20:55:38 2005
lknuhst.sys  Thu Dec 14 22:11:24 2006
lknuhub.sys  Thu Dec 14 22:11:15 2006
cygwin1.dll  Fri Dec 14 19:21:07 2007


Weaknesses: Excessive computation. Isolated code.

Strengths: Original and provocative UI. Daring computation.

Advice: Make your code fix suggestions quietly while carefully considering what you propose and what you say to another engineer. Choose the middle way in troubleshooting, debugging and code reviewing and be philosophical with your peers, internal and external customers.

- Dmitry Vostokov @ SoftwareAstrology.com -

The Day of Software Craft

Modules, products or systems built on December 13 strive to compute every detail. They do it so precisely without departing from the big picture of their computational goals that there is a danger that they become stuck. Being a kind of computational psychologists or detectives they can go though interface facades and various superfluous defences. As a result components build on December 13 must respect privacy. Modules, products or systems built on December 13 are mostly crafted to help with the design of objects and less often to output persistent data. Unfortunately they can show erratic behaviour, component peculiarities and create difficulties in maintenance. Components build on December 13 should adapt themselves to be not so demanding and compromise for the harmony of computation. Being designed for design, products and subsystems built on December 13 can be overly concerned with self-checks and have strange built-in computational paths to deal with troubles. Good maintainer who is sceptical about the latest software engineering methodologies and tools is their best friend. Readjustments of their detail-driven event processing and moderate computation are encouraged.

DLL, SYS and EXE born on this date:

oleaut32.dll    Thu Dec 13 08:49:29 2007
srv.sys         Wed Dec 13 21:19:02 2000
taskhost.exe    Sat Dec 13 02:02:54 2008
uhcd.sys        Sat Dec 13 02:37:25 2003
usbehci.sys     Sat Dec 13 02:37:43 2003
kdcom.dll       Sat Dec 13 00:28:28 2008
hal.dll         Sat Dec 13 00:24:05 2008
mcupdate_GenuineIntel.dll Sat Dec 13 00:26:34 2008
PSHED.dll       Sat Dec 13 00:32:30 2008
CI.dll          Sat Dec 13 00:32:19 2008
cdd.dll         Sat Dec 13 00:19:06 2008
symmpi.sys      Mon Dec 13 21:03:14 2004
dump_symmpi.sys Mon Dec 13 15:03:14 2004
dump_arcsas.sys Wed Dec 13 11:54:58 2006
arcsas.sys      Wed Dec 13 11:54:58 2006
metsrv.dll      Tue Dec 13 05:10:41 2005

Weaknesses: Disturbing computation. Irritating UI.

Strengths: Attentive and perceptive UI. Thoughtful code.

Advice: Keep moving on when you finish your piece of code. Remember about good enough rule when feeling urge to polish code again and again.

- Dmitry Vostokov @ SoftwareAstrology.com -

• Days of possible critical problems: 3, 11
• Days of unfortunate computation: 7, 15, 26
• Days of good enough software behaviour: 5, 13, 23
• Fault-free days: 9, 18, 28

- Dmitry Vostokov @ SoftwareAstrology.com -