Solutions:
1. Recommend him for a position somewhere else in the company or beyond...
2. Tell him his laugh is a little distracting at times
3. Tell him that girl in marketing keeps asking about him, you've heard she wants him to ask her out - but that she'll probably turn him down the first ten or so times he asks
4. Enlist him in the National Guard
5. Add a link to a porn site in one of his friend's blogs - and turn him in when he follows it
6. Ask to be moved, or ask to have him moved
7. Pay to have a leadership coach to come in and tell him his laugh is annoying
8. Make him beleive that everyone else in the department is making 2x as him
Leaving off the sig for productivity sake.
With all the comments almost wonder if this is a troll...but here goes...
Stable (or ultra-stable) software is a combination of many things. This includes at least; requirements gathering, architecture, design, coding, QA, configuration and realease management, project management, training of developers/qa/project managers/business analysts i.e. the software development/engineering process.
Far down the list, in my opinion, is choice of language. Not that languages don't have relative strengths and weaknesses, but to think that choice of language will be the first, second or third determining factor in software stability is like wearing a seatbelt but driving blindfolded while intoxicated 155 mph in a yugo in a blinding snowstorm...you can gain some incremental survivability...but probably will add a few painful milliseconds to your life expectancy.
Assuming you have a full grasp of the requirements, including the beginnings of your test plans, it sounds like architecture is a good place to begin.
The fact that you are thinking about architecture concepts early is a good sign, and a modular approach is a good start. I would say the CORBA, SOAP or just plan XML messaging probably is a reasonable place to begin your inter-module communications thoughts. Make sure that you spend some time thinking about testability in your architecture - i.e. how can I test each module on a stand alone basis. There are some hardware architecture things you can add later (deploying software layers onto separate machines, adding redundancy etc.).
Once you have solid beginning software architecture, intense OOAD is in order. Mistakes here have huge downstream affects, some almost unrecoverable without throwing away huge chunks of code - so measure twice cut once so to speak. Not sure if there is a DB in the picture - but some thought about data elements and relationships is pretty important here as well...Design in testability...
Slashdot Mirror
Solutions: 1. Recommend him for a position somewhere else in the company or beyond... 2. Tell him his laugh is a little distracting at times 3. Tell him that girl in marketing keeps asking about him, you've heard she wants him to ask her out - but that she'll probably turn him down the first ten or so times he asks 4. Enlist him in the National Guard 5. Add a link to a porn site in one of his friend's blogs - and turn him in when he follows it 6. Ask to be moved, or ask to have him moved 7. Pay to have a leadership coach to come in and tell him his laugh is annoying 8. Make him beleive that everyone else in the department is making 2x as him Leaving off the sig for productivity sake.
Stable (or ultra-stable) software is a combination of many things. This includes at least; requirements gathering, architecture, design, coding, QA, configuration and realease management, project management, training of developers/qa/project managers/business analysts i.e. the software development/engineering process.
Far down the list, in my opinion, is choice of language. Not that languages don't have relative strengths and weaknesses, but to think that choice of language will be the first, second or third determining factor in software stability is like wearing a seatbelt but driving blindfolded while intoxicated 155 mph in a yugo in a blinding snowstorm...you can gain some incremental survivability...but probably will add a few painful milliseconds to your life expectancy.
Assuming you have a full grasp of the requirements, including the beginnings of your test plans, it sounds like architecture is a good place to begin.
The fact that you are thinking about architecture concepts early is a good sign, and a modular approach is a good start. I would say the CORBA, SOAP or just plan XML messaging probably is a reasonable place to begin your inter-module communications thoughts. Make sure that you spend some time thinking about testability in your architecture - i.e. how can I test each module on a stand alone basis. There are some hardware architecture things you can add later (deploying software layers onto separate machines, adding redundancy etc.).
Once you have solid beginning software architecture, intense OOAD is in order. Mistakes here have huge downstream affects, some almost unrecoverable without throwing away huge chunks of code - so measure twice cut once so to speak. Not sure if there is a DB in the picture - but some thought about data elements and relationships is pretty important here as well...Design in testability...
Code (including adding testability)...
QA
Iterate
I am pretty sure that they are actually an LLC, although taxed as a partnership. --