The problem that software professionals have with VB is that it has allowed hacker office types to produce something they cannot be responsible for, forcing them to leave their wonderful project on the doorstep of the IT department when it gets hard.
It's the same as handing a sixteen year old a socket set so he can maintain his own car. He'll change the oil perhaps, but when he decides to make it a hot rod he'll end up pushing it to a mechanic to make it run at all.
First, are you really going to be a 'big shop'? If it's possible for you to know all the names of everyone on your staff, you're not a big shop. You're still going to hunt down your top performers by name when something important needs done. That's not big shop.
If you are indeed going to be a big shop, you've got to make the business bigger than its people. The business has to go on no matter who, so long as they're capable, is in a position. Because in a big shop you don't always know who is doing something and whether it's going to be done right, you MUST put a measurable process in place. You've got to be able to hand off a task as a transaction and to measure that it's being done right, not just say, "Oh, Joe's working on that and we know he's top grade." Define your process, work by a process, and when it doesn't work treat it as a special case. Either move that single particular task outside of process until you can put it back in, or consciously and deliberately adjust your process. DO NOT fall back into letting your top guys save the day. They'll get tired of that and go save the day for someone who can pay them more.
Because the business in a big shop is bigger than its people, you've got to do what's right for the business, even if good people won't necessarily be treated with the respect they might think they deserve. Your top IT guy who's been with the company from its start may feel he should be in a manager position. But if he can't manage, if he's not someone who can recognize when things need to be taken out of process and manipulated, or if he can't own and orchestrate the process, leave him where he is and hire a good manager. Insightful, assertive, authoritative management is going to save you and your customer relationships more times than a wizard coder. The wizard coder makes it a viable product. The manager makes your business around the product successful. You've all seen enough marginal product to know that wizard managers win over wizard coders.
Specializing will ALWAYS mean that you're at the mercy of the next technology and those who are introduced to it as youngsters. When some youngster who works for entry level or just above can compete with you when you've got ten years experience -- and ten years of salary expectations -- you're gonna be out on your ear with an old man's bills and an old man's willingness to change.
Learn the fundamentals of software and business use of it. Learn what it takes to make and keep an organization successful. Learn how to identify what the real problem is, how to craft a real solution, and how to implement it so that the next generation on the software will be able to maintain it. Better yet, how to tell someone how to implement it that way. Problem solving skills and insight are going to stick with you far longer than the technology of today (or yesterday on some things already).
I've been developing for over a dozen years, from PC database in the Clipper days, to Unix C/C++, now to J2EE and web. Rather than focus on technology I focused on understanding what it takes to be successful in software. The most skilled, sophisticated coder isn't going to be successful if they're solving the wrong problem, or part of hte problem, or someone else's problem. Or if their solution isn't appropriate. The organization isn't going to remain successful after launch if the design or the technology isn't somethign that can be maintained by the staff that's going to follow up the initial development, or if non-functional requirements regarding the need for change are ignored. Focusing on understanding that part of the software problem has me moving into a Director of Technology position at age 35. I went into a firm applying for a project lead position and when I was done with the interview the VP told me to go home and figure out what it would take to be their director. It sure wasn't because I know Struts/Hibernate/Spring/"buzzword of the day". The industry as a whole needs more people who can think above the keyboard and know how their organization works and what it needs to survive. If you were on a failing software project recently, was it because you and the end-developers couldn't write code? If you're in a mess of a software house, is it because the team couldn't make Spring or Hibernate or Struts or whatever work? Not very likely. If you want a long term career, solve the real problems of IT and the business that relies on IT.
What companies have discovered is that buzz-word tech skill is easy to not going to save their business. They're putting their money into business analysis and real problem solving skills, knowing that if they get that right the coding is the easy part.
We've just turned the corner from the blacksmith age of software develoment into the engineering stage. Once you'd walk into a blacksmith shop and say, "I need a widget like this." It was up to the blacksmith to know how to make the widget, what to make it out of, and to get it done. Software has been like this for years. Now with more sophisticated languages, frameworks, tools, etc. it's easy to make software.
But as the bar lowered on entry into the technology field the quality of the product has declined because though almost anyone can write software, few know very well what software to write. So now the focus is shifting to the engineer, the one who can see the problem and craft a solution. The solution then goes to the craftsmen who know how to make software from a spec.
Some day, perhaps in the next 10-20 years, there will be a software engineering diagram like there is for most manufactured items. At that point the production of software can be automated as today the crafting of physical items can be.
That's the holy grail of software. The Software Engineering Diagram, with dimensions and tolerances and component diagrams that tell very precisely how things fit together. Until we have that, people who want a serious IT career need to stay focused on the problem and the solution, not the manufacturing of software components. That end of things will continue to decline in significance.
The way to protect yourself in the IT world is to focus on the 'I' and less on the 'T'. I've been in the software business for over a dozen years, and the one thing I've learned so very clearly is that the technology isn't the challenge. The challenge is finding a business person who knows what the problem is, and then finding technology people who can craft a sensible solution to the problem.
In the business software world, no matter what you're trying to achieve with it, there are inherent risks that don't go away, no matter what your methodology or technology might be. Do you know the real problem? Do you know the whole problem? Is it your problem? If you don't have appropriate answers to those, every line of code you write is likely to be a waste.
Once you have those answered appropriately, are you implementing a real process? Do the steps in the process mitigate real risks in the appropriate order on behalf of the people who should be managing those risks? This is one of the primary failings of corporate software. I've worked at some very large, supposedly very sophisticated client sites and they fail this miserably. Like on Lost, people keep pressing the buttons without knowing why or what might happen if they stop. But since "It's always been that way" people think it's meaningful and/or valuable.
If you can get a real solution that solves a real problem effectively, you can then find anyone with technical capabilities to satisfy the solution.
While that portion of the problem may go overseas or otherwise be marginalized, people like myself who specialize in satisfying the hard part of IT, the understanding of the problem and crafting a business solution, find ourselves in ever greater demand and reaping a great deal of compensation.
Someone's always going to bone up on the latest buzz word technology. Few of those people are going to know how to save a company with them.
Your grasp of syllogistic logic appears limited. The placement of a negative in a single clause of a statement of an argument has no effect on the evaluation of that clause. "I believe it is not true" is exactly the same as saying "I believe it is false", which is exactly the same as saying "I do not believe it is true."
What you are wrestling with in the semantics of your argument is whether it is your basis of belief or mine that is in question. With regard to the argument though that is immaterial. That comes out as an application of the evaluated logic of the argument.
The argument, in syllogistic form, is something like this:
It is claimed that Jesus walked on water, so that is the conclusion we're trying to support "Jesus walked on water" To argue that we need at least two premises. We in fact have a few more.
A - Jesus was a man B - Water, in readily found purity and environmental conditions, has a surface tension of X C - X is less than that required for the support of a man
therefor D - Jesus walked on water.
I don't think you'd quibble with the premises A-C. It's clear that the premises do not suppor the conclusion D.
What is required to make this argument true has to be the successful contradiction of one or more of those premises or the introduction of another that negates the impact of one of those others.
I contend that you cannot contradict one of the first three. A Christian refuting A is refuting one of the religious tenets, and I won't refute it because if Jesus wasn't a man then the entire basis for the discussion is in question. B and C are empirical measurements. Somewhere in a science book on fluids we can know the behavior of water, and from that we should be able to make a definitive statement about water supporting the weight of a man in the action of walking. Real-world experience says, even without the measurement or knowing the true conditions of the event, that it's very highly probable that D is a true statement. High enough to call it a true statement.
Now, for you to maintain that the conclusion is true in light of the affirmative evaluation of premises A-C, you have to add a premise that I would say is entirely unsupportable.
The obvious additional premises to be added are that E - Jesus is God and F - God can walk on water. Both of which have no basis other than the arbitrary documentation of such in an unverifiable text. Therefore they cannot contribute to a proper argument.
Which means that at that point you have abandoned logic, and thereby reason in general. Nothing other than willful suspension of reason can validate a position that contends that Jesus walked on water.
Now, if we should conclude that the argument is false, the application of that conclusion can only result in the abandoning of the idea that Jesus walked on water. No matter how we stated problem initially.
No, my argument regarding walking on whater is based on what we know of the capability of the people of that time of history. For the events portrayed to have happened the relatively ignorant and unsophisticated people of that time would have had to manipulate water at the molecular level. Considering the molecular model was not even conceived and that even rudimentary chemistry was not in play at the time, the overwhelming probability is that it didn't happen. Meanwhile, there is outstanding probability, based on human nature and the vagaries of language and translation, that the story is simply fiction or gross exageration. Only someone with a willful disbelief would abandon the outstandingly probabile for the extraordinarily unlikely.
Based on your argument, anything one cares to believe is just as valid and plausible as anything else, regardless of evidence and reason, if there is not direct incontrovertable proof. That is a ludicrous position. It's willful susupension of reason. It's fortunate that religion deals with topics that we don't depend on for our daily continued existence.
Your example of the jumbo jet is entirely backward. A scientist of 1750 making that statement would not have been in direct contradiction to anyone's empirical evidence. In fact, nothing that was made of steel in 1750 was flying, so the statement was consistent.
Now, if he'd ground up the bones from a robin and weighed it and declared that everythign with no more than 75 grams of bone could fly, why then he would be wrong. Science already knew that bird bones were hollow and that their wing structure and feathers promoted flight, and that the solid bones and leg structure of a mole do not.
Now, there's no proof that a mole hasn't flown, but we don't go around talking about the flying mole now, do we. No one would take us seriously. Isn't the flying mole just as plausible as a man walking on water? If I care to believe it and you can't prove that the magic mole god didn't fly one day?
Why can you suspend your reason for biblical stories, but sort out that the flying mole is likely bunk? Why do we disbelieve our chum who claims to have drunk 30 pints in an outing, but Christains believe that Jesus kept the wine flowing for the big wedding by creating more?
Religion is based on unsubstantiable claims that are in direct opposition to observable natural phenomenon. In the case of Christianity, water's surface tension does not support the weight of a human. Water cannot be turned into wine with first century technology. There is no produceable evidence of any form of sentience, or any personal phenomenon at all, after death. There is no produceable evidence of a soul.
Therefore, for an individual to maintain a system of belief that includes any religious basis is to maintain an inconsistent system of beliefs. There can be no sound judgement when an issue requires the mixing of understanding based on sound empiracle evdience and that based on arbitrary religious declarations that are contrary to that evidence.
It's not that religion is contradicting itself. I's that religion contradicts observable, reproduceable, objective experience in the every day world. And people still use it as a basis for decision making. That, in my opinion, is faulty.
The point wasn't whether science has arrived at objective truth. There is still uncertainty in science. Often it is practically zero, but nonetheless it's still there. The point, rather, is that religion requires that you maintain a self-contradicting position. I can at least offer evicence of gravity, the particle/wave behavior of light. There is no produceable or even predictable evidence of life after death, the soul, sin, blessedness, etc.
Even the suggested health benefits of prayer do nothing to link the effect to anything that other self-delusions cannot likely reproduce. The problem is, it's unethical to subject a person to decades of indoctrination and brain washing to replicate the effect.
Any system of belief that one maintains which puts provable truth alongside contradictory unprovable belief is simply false. More simply, you can't have it both ways. And since science is about provable truth and religion is based on faith, which rather implies unprovable contradictions, anyone clinging to religion is simply wrong. Regarding Christianity, from direct measurement of the surface tension of water there's nothing regarding water that could ever suggest that one might walk on it. Very likely no technology of the late pre-Christian time could manipulate water molecules to transform them into simple hydrodgen and oxygen, much less wine. Nothing we know of modern medicine suggests that once truly clinically dead a person may be brought back to life.
If your version of truth maintains two principles that are directly contradictory or are contradictory due to underlying principles, there can be no other conclusion than that your understanding of the truth is corrupted.
Indubitably, any subscription to religion puts you in that position.
plethora Audio pronunciation of "plethora" ( P ) Pronunciation Key (plthr-) n.
1. A superabundance; an excess.
Just because there is a large number or an outstanding variety doesn't mean there is a PLETHORA! And just because you've seen a word used (likely incorrectly) in a PLETHORA of other weakly written articles doesn't mean it's the word to use.
When you have an excess, some of the sample is less significant than others. Some was required to satisfy a need. Some beyond that measure were less significant. I can't imagine that being what you intended to say by using the word plethora. Now I don't know what you intended to say, leaving me to question if you are qualified to be making any statement at all.
What you found was likely a VARIETY of reasons that have failed to indicate a trend. If that's the case, why didn't you say so?
I won't tell you where to send your resume, but I'll give some hints on what to put on it.
Put on it how you've helped your organization develop software that's valuable for the long term. Tell that hiring manager how you structured the app to be responsive to change and adaptable to expanding/changing technology sectors. Tell him how you've helped the business people create a business process model and engineered your software around that model so that they can be clear when they talk about changes and you'll know what the impact ot the system is going to be. Tell him how you've architected your software in terms of simple, consistent components, so that when a change request comes in you can give me a list of components to be changed or added and have a real idea of the cost of that change, not a shot in the dark that's going to blow the budget because you missed half the work.
Programmers, those guys who sit and complain about requirements, bang out something at the last minute that hamstrings them for the next round, and prop themselves up for saving the day when in reality they've missed the bigger mark altogether, are in generall getting what they're worth.
Responsible software developers, those who know what is important to their organizations future and know how to make their software reflect that, are getting much more, and are in much bigger demand.
I'm pulling in $50/hr and doing about 45-50 hours a week. I've got a degree in Comp. Sci. and have 10+ years of corporate experience. I'm a contractor for a firm who's billing me at $75/hr, but that ratio is about to change. More's coming my way.
My success is coming from the fact that I can make the organizations I go into better able to be successful software shops. I went in as a senior general developer type. In the last year I've done very little real develoment. Instead, I've invented a new software document management system for the client. I've helped them figure out why they can't get software out the door, and why what they do get released is failing. Now I'm helping them kick off a multi-year re-architecture project for their entier hiring system. It's NOT because I'm a genius Java developer. I'm not. It's because I've found the principles behind software value. Simple, structured, flexible.
If you want to make money in this business, learn to do MORE than program and bitch about poor requirements. Learn how to make your organization better. Yes, they can indeed find good programmers for less money. So make yourself more valuable than Joe Programmer. Learn how to be responsible to your organization. Learn what it takes to make long-term value in your software, not the latest whiz-bang that's going to flip the next pore sod's wig when he has to figure it out. Learn how to deliver faster code that's more solid and easy to understand. And then learn how to teach others to do it. If you can do that, there will be a line outside your cubicle of people wanting you to work for them.
If you can't do that, either your days or numbered or you're setting your earningsceiling is pretty low. You're a commodity, and not a popular one.
There's a risk assessment tool that has a x-y graph. One axis is probability, the other is consequence. Going up the diagonal has high probability and high consequence. AS population grows we're putting more poeple along that axis. Not only are we putting communities where they're more liekly to have trouble, we're putting htem in places where the consequences are going to be more grave.
Rather than giving them just a budget, set some baseline technology objectives for the firm and use them to guide spending. Things like, "No front-line PCs over 2 years old." "No piece of equipment costing more than 30% of replacement cost to keep running." "No LAN speed less than 100Mb/s in the infrastructure." "No piece of enterprise software more than 1 major revision behind current."
These things will be guidelines that will let you count hte cost to get to the standard, and give guidelines on future spending as well.
Documents rot because no one USES the documents. I'm in the middle of a situation for my client where their ability to make code corrections or enhancements is compromized by the complexity (unnecessary) of the code and the loss of justification for why it is that way. So now they've asked me to help them dig out. One of the most common questions is, "Who's going to maintain all this documentation?"
My answer is that there is never a reason to MAINTAIN documentation. If you have to maintain it, throw it away. But if you're going to USE the documentation as part of your problem solving and day-to-day routine you'll be developing it just as much as you are your code. An analyst or system architect should express teh solution in the documentation, or more accurately the model. They hand off hte task and the solution in the documentation to the developer. They use the documentation justify and guide what they're doing. It has to be part of how you work.
See my earlier post about a design documentation philosophy. Your maintained model should be just enough to springboard any decision making about your system. Then work out from there into specifics about your task at hand. Start from your accurate baseline model. Build the new one from the current implementation. Validate that with the business peo ple to make sure it's correct, and make your design and implementation decisions. Do the work. When you're done you can throw that away because the task for which it was created is completed.
Like I said before, the purpose of Analysis, design, and documentation is to improve the probability that any development activity is successful. Do enough to achieve that and no more. Doing less is assuming unnecessary risk. Doing more is wasteful.
You can't ask for a good "design document". No single document is going to be sufficient for transfering design knowledge to every developer and analyst on a system. You need to have a good design documentation PHILOSOPHY.
I've been an analyst and coder and now system architect on a number of systems. My philosophy is to create a baseline system model that is the starting point of every discussion about the system. It is generally not detailed enough to answer any question about the system, but the important point is that IT IS ALWAYS ACCURATE! This model is the starting point of every discussion. We then look at the decisions being made and we start on a more detailed model that is tailored to those. That model -- diagrams, text, etc. -- is generally not proper for any other decisions because it's not focused for any other decisions. You have to do it again for every significant decision making session. That may seem like waste, but there are two important points.
First, we ALWAYS start from an accurate model. Any decision made from an inaccurate model may be inaccurate, and that means improper design, coding, testing, and delivery. In other words, defects. If your baseline model is not accurate you've changed underlying business objectives. That means you have a LOT of work to do. It should scare people when your baseline model becomes innacurate.
Second, we deal only with the information that is important for our current decisions. We have an accurate picture without distractions from extra information, too much detail, etc. We all know we can't maintain a detailed model. Software changes too frequently and deadlines don't let us spend the time we might need to maintain a fully detailed model. And we most of the time won't need a fully detailed model, just enough to make the decisions at hand. So don't try. Keep just enough to start from and go just far enough as required when you need to.
So, in short, develop a system model that has enough detail to springboard your development process, but not so detailed that it's hard to maintain and that it carries baggage to discussions that doesn't need to be there. This model will become the paper that everyone recognizes and everyone carries around to meetings. When that paper is insufficient for your decision making, let your analyst or system architect work with you to get you a more detailed model. When you're done, throw that one away because it'll probably be obsolete by the time you're done with your coding anyway. It certainly won't be pertinent to your next decision making and design activity unless you screw up the one that brought it about.
No methodology will tell you to do it this way. But then, I've never seen any named methodology ever executed to its fullest. No one can afford to do it.
The point of analysis, design, and documentation is to improve the probability that any development task will be successful. Out of the box, no methodology can guarantee that. But, if you approach analysis, design, and documentation with this as your objective -- making development successful -- you can use any methodology you want and adapt it as necessary. If you know your business people, your developers, and your processes you can take any methodology as far as it needs to go to improve that probability of success.
The fact that this can even be entertained as a rational suggestion is all the evidence necessary to conclude that the software industry is not about providing long term viable solutions to real business problems.
Robust, maintainable, well-behaved software that will stand the tests of time and budget CANNOT be arrived at by a PROGRAMMER. A PROGRAMMER will not acknowledge that there are more meaningful measures of design value than a nice algorithm or the latest industry buzz words.
We've done it for years. Forward your cell phone to whomever you wish to call, and then call your cell phone. We did this all through college to get free long distance. The call from local land line to local cell was free, no cell minutes used since the phone was never activated.
But then the rules may have changed since those years. And now I'm a successful adult who doesn't care that I have a $250 a month cumulative phone bill.
People are on good behavior first out of hte gate. Then, when they're more comfortable with those around them, after usually 3-5 months into the school year, they start taking what they like. Don't fall into the trap of trusting those you've made your friends in the first of the year. One of them will screw you somehow.
Java made it's way into the web paradigm. In the last 6 years I've never seen a web or any Java application taken nearly as seriously as anything I've been asked to do in C/C++. They just don't expect you to work as hard in the Java world. Anyone can do it, so it must be easy. If you're working hard at it you must suck.
Slashdot Mirror
The problem that software professionals have with VB is that it has allowed hacker office types to produce something they cannot be responsible for, forcing them to leave their wonderful project on the doorstep of the IT department when it gets hard.
It's the same as handing a sixteen year old a socket set so he can maintain his own car. He'll change the oil perhaps, but when he decides to make it a hot rod he'll end up pushing it to a mechanic to make it run at all.
First, are you really going to be a 'big shop'? If it's possible for you to know all the names of everyone on your staff, you're not a big shop. You're still going to hunt down your top performers by name when something important needs done. That's not big shop.
If you are indeed going to be a big shop, you've got to make the business bigger than its people. The business has to go on no matter who, so long as they're capable, is in a position. Because in a big shop you don't always know who is doing something and whether it's going to be done right, you MUST put a measurable process in place. You've got to be able to hand off a task as a transaction and to measure that it's being done right, not just say, "Oh, Joe's working on that and we know he's top grade." Define your process, work by a process, and when it doesn't work treat it as a special case. Either move that single particular task outside of process until you can put it back in, or consciously and deliberately adjust your process. DO NOT fall back into letting your top guys save the day. They'll get tired of that and go save the day for someone who can pay them more.
Because the business in a big shop is bigger than its people, you've got to do what's right for the business, even if good people won't necessarily be treated with the respect they might think they deserve. Your top IT guy who's been with the company from its start may feel he should be in a manager position. But if he can't manage, if he's not someone who can recognize when things need to be taken out of process and manipulated, or if he can't own and orchestrate the process, leave him where he is and hire a good manager. Insightful, assertive, authoritative management is going to save you and your customer relationships more times than a wizard coder. The wizard coder makes it a viable product. The manager makes your business around the product successful. You've all seen enough marginal product to know that wizard managers win over wizard coders.
Specializing will ALWAYS mean that you're at the mercy of the next technology and those who are introduced to it as youngsters. When some youngster who works for entry level or just above can compete with you when you've got ten years experience -- and ten years of salary expectations -- you're gonna be out on your ear with an old man's bills and an old man's willingness to change.
Learn the fundamentals of software and business use of it. Learn what it takes to make and keep an organization successful. Learn how to identify what the real problem is, how to craft a real solution, and how to implement it so that the next generation on the software will be able to maintain it. Better yet, how to tell someone how to implement it that way. Problem solving skills and insight are going to stick with you far longer than the technology of today (or yesterday on some things already).
I've been developing for over a dozen years, from PC database in the Clipper days, to Unix C/C++, now to J2EE and web. Rather than focus on technology I focused on understanding what it takes to be successful in software. The most skilled, sophisticated coder isn't going to be successful if they're solving the wrong problem, or part of hte problem, or someone else's problem. Or if their solution isn't appropriate. The organization isn't going to remain successful after launch if the design or the technology isn't somethign that can be maintained by the staff that's going to follow up the initial development, or if non-functional requirements regarding the need for change are ignored. Focusing on understanding that part of the software problem has me moving into a Director of Technology position at age 35. I went into a firm applying for a project lead position and when I was done with the interview the VP told me to go home and figure out what it would take to be their director. It sure wasn't because I know Struts/Hibernate/Spring/"buzzword of the day". The industry as a whole needs more people who can think above the keyboard and know how their organization works and what it needs to survive. If you were on a failing software project recently, was it because you and the end-developers couldn't write code? If you're in a mess of a software house, is it because the team couldn't make Spring or Hibernate or Struts or whatever work? Not very likely. If you want a long term career, solve the real problems of IT and the business that relies on IT.
What companies have discovered is that buzz-word tech skill is easy to not going to save their business. They're putting their money into business analysis and real problem solving skills, knowing that if they get that right the coding is the easy part.
We've just turned the corner from the blacksmith age of software develoment into the engineering stage. Once you'd walk into a blacksmith shop and say, "I need a widget like this." It was up to the blacksmith to know how to make the widget, what to make it out of, and to get it done. Software has been like this for years. Now with more sophisticated languages, frameworks, tools, etc. it's easy to make software.
But as the bar lowered on entry into the technology field the quality of the product has declined because though almost anyone can write software, few know very well what software to write. So now the focus is shifting to the engineer, the one who can see the problem and craft a solution. The solution then goes to the craftsmen who know how to make software from a spec.
Some day, perhaps in the next 10-20 years, there will be a software engineering diagram like there is for most manufactured items. At that point the production of software can be automated as today the crafting of physical items can be.
That's the holy grail of software. The Software Engineering Diagram, with dimensions and tolerances and component diagrams that tell very precisely how things fit together. Until we have that, people who want a serious IT career need to stay focused on the problem and the solution, not the manufacturing of software components. That end of things will continue to decline in significance.
The way to protect yourself in the IT world is to focus on the 'I' and less on the 'T'. I've been in the software business for over a dozen years, and the one thing I've learned so very clearly is that the technology isn't the challenge. The challenge is finding a business person who knows what the problem is, and then finding technology people who can craft a sensible solution to the problem.
In the business software world, no matter what you're trying to achieve with it, there are inherent risks that don't go away, no matter what your methodology or technology might be. Do you know the real problem? Do you know the whole problem? Is it your problem? If you don't have appropriate answers to those, every line of code you write is likely to be a waste.
Once you have those answered appropriately, are you implementing a real process? Do the steps in the process mitigate real risks in the appropriate order on behalf of the people who should be managing those risks? This is one of the primary failings of corporate software. I've worked at some very large, supposedly very sophisticated client sites and they fail this miserably. Like on Lost, people keep pressing the buttons without knowing why or what might happen if they stop. But since "It's always been that way" people think it's meaningful and/or valuable.
If you can get a real solution that solves a real problem effectively, you can then find anyone with technical capabilities to satisfy the solution.
While that portion of the problem may go overseas or otherwise be marginalized, people like myself who specialize in satisfying the hard part of IT, the understanding of the problem and crafting a business solution, find ourselves in ever greater demand and reaping a great deal of compensation.
Someone's always going to bone up on the latest buzz word technology. Few of those people are going to know how to save a company with them.
Your grasp of syllogistic logic appears limited. The placement of a negative in a single clause of a statement of an argument has no effect on the evaluation of that clause. "I believe it is not true" is exactly the same as saying "I believe it is false", which is exactly the same as saying "I do not believe it is true."
What you are wrestling with in the semantics of your argument is whether it is your basis of belief or mine that is in question. With regard to the argument though that is immaterial. That comes out as an application of the evaluated logic of the argument.
The argument, in syllogistic form, is something like this:
It is claimed that Jesus walked on water, so that is the conclusion we're trying to support "Jesus walked on water" To argue that we need at least two premises. We in fact have a few more.
A - Jesus was a man
B - Water, in readily found purity and environmental conditions, has a surface tension of X
C - X is less than that required for the support of a man
therefor
D - Jesus walked on water.
I don't think you'd quibble with the premises A-C. It's clear that the premises do not suppor the conclusion D.
What is required to make this argument true has to be the successful contradiction of one or more of those premises or the introduction of another that negates the impact of one of those others.
I contend that you cannot contradict one of the first three. A Christian refuting A is refuting one of the religious tenets, and I won't refute it because if Jesus wasn't a man then the entire basis for the discussion is in question. B and C are empirical measurements. Somewhere in a science book on fluids we can know the behavior of water, and from that we should be able to make a definitive statement about water supporting the weight of a man in the action of walking. Real-world experience says, even without the measurement or knowing the true conditions of the event, that it's very highly probable that D is a true statement. High enough to call it a true statement.
Now, for you to maintain that the conclusion is true in light of the affirmative evaluation of premises A-C, you have to add a premise that I would say is entirely unsupportable.
The obvious additional premises to be added are that E - Jesus is God and F - God can walk on water. Both of which have no basis other than the arbitrary documentation of such in an unverifiable text. Therefore they cannot contribute to a proper argument.
Which means that at that point you have abandoned logic, and thereby reason in general. Nothing other than willful suspension of reason can validate a position that contends that Jesus walked on water.
Now, if we should conclude that the argument is false, the application of that conclusion can only result in the abandoning of the idea that Jesus walked on water. No matter how we stated problem initially.
No, my argument regarding walking on whater is based on what we know of the capability of the people of that time of history. For the events portrayed to have happened the relatively ignorant and unsophisticated people of that time would have had to manipulate water at the molecular level. Considering the molecular model was not even conceived and that even rudimentary chemistry was not in play at the time, the overwhelming probability is that it didn't happen. Meanwhile, there is outstanding probability, based on human nature and the vagaries of language and translation, that the story is simply fiction or gross exageration. Only someone with a willful disbelief would abandon the outstandingly probabile for the extraordinarily unlikely.
Based on your argument, anything one cares to believe is just as valid and plausible as anything else, regardless of evidence and reason, if there is not direct incontrovertable proof. That is a ludicrous position. It's willful susupension of reason. It's fortunate that religion deals with topics that we don't depend on for our daily continued existence.
Your example of the jumbo jet is entirely backward. A scientist of 1750 making that statement would not have been in direct contradiction to anyone's empirical evidence. In fact, nothing that was made of steel in 1750 was flying, so the statement was consistent.
Now, if he'd ground up the bones from a robin and weighed it and declared that everythign with no more than 75 grams of bone could fly, why then he would be wrong. Science already knew that bird bones were hollow and that their wing structure and feathers promoted flight, and that the solid bones and leg structure of a mole do not.
Now, there's no proof that a mole hasn't flown, but we don't go around talking about the flying mole now, do we. No one would take us seriously. Isn't the flying mole just as plausible as a man walking on water? If I care to believe it and you can't prove that the magic mole god didn't fly one day?
Why can you suspend your reason for biblical stories, but sort out that the flying mole is likely bunk? Why do we disbelieve our chum who claims to have drunk 30 pints in an outing, but Christains believe that Jesus kept the wine flowing for the big wedding by creating more?
Religion is based on unsubstantiable claims that are in direct opposition to observable natural phenomenon. In the case of Christianity, water's surface tension does not support the weight of a human. Water cannot be turned into wine with first century technology. There is no produceable evidence of any form of sentience, or any personal phenomenon at all, after death. There is no produceable evidence of a soul.
Therefore, for an individual to maintain a system of belief that includes any religious basis is to maintain an inconsistent system of beliefs. There can be no sound judgement when an issue requires the mixing of understanding based on sound empiracle evdience and that based on arbitrary religious declarations that are contrary to that evidence.
It's not that religion is contradicting itself. I's that religion contradicts observable, reproduceable, objective experience in the every day world. And people still use it as a basis for decision making. That, in my opinion, is faulty.
Prayer may have been coincidental to reduced mortality, but probably so was the rate of toe fungus, red hair, and cooties.
Statistical similarity does not imply causality or relationship in any fasion.
The point wasn't whether science has arrived at objective truth. There is still uncertainty in science. Often it is practically zero, but nonetheless it's still there. The point, rather, is that religion requires that you maintain a self-contradicting position. I can at least offer evicence of gravity, the particle/wave behavior of light. There is no produceable or even predictable evidence of life after death, the soul, sin, blessedness, etc.
Even the suggested health benefits of prayer do nothing to link the effect to anything that other self-delusions cannot likely reproduce. The problem is, it's unethical to subject a person to decades of indoctrination and brain washing to replicate the effect.
Any system of belief that one maintains which puts provable truth alongside contradictory unprovable belief is simply false. More simply, you can't have it both ways. And since science is about provable truth and religion is based on faith, which rather implies unprovable contradictions, anyone clinging to religion is simply wrong. Regarding Christianity, from direct measurement of the surface tension of water there's nothing regarding water that could ever suggest that one might walk on it. Very likely no technology of the late pre-Christian time could manipulate water molecules to transform them into simple hydrodgen and oxygen, much less wine. Nothing we know of modern medicine suggests that once truly clinically dead a person may be brought back to life.
If your version of truth maintains two principles that are directly contradictory or are contradictory due to underlying principles, there can be no other conclusion than that your understanding of the truth is corrupted.
Indubitably, any subscription to religion puts you in that position.
The ruling is about setting a curriculum, not about dialogue.
plethora Audio pronunciation of "plethora" ( P ) Pronunciation Key (plthr-)
n.
1. A superabundance; an excess.
Just because there is a large number or an outstanding variety doesn't mean there is a PLETHORA! And just because you've seen a word used (likely incorrectly) in a PLETHORA of other weakly written articles doesn't mean it's the word to use.
When you have an excess, some of the sample is less significant than others. Some was required to satisfy a need. Some beyond that measure were less significant. I can't imagine that being what you intended to say by using the word plethora. Now I don't know what you intended to say, leaving me to question if you are qualified to be making any statement at all.
What you found was likely a VARIETY of reasons that have failed to indicate a trend. If that's the case, why didn't you say so?
What a stupid topic. Why waste space here on such a ridiculous matter. It's their world, and it's just a name.
I won't tell you where to send your resume, but I'll give some hints on what to put on it.
Put on it how you've helped your organization develop software that's valuable for the long term. Tell that hiring manager how you structured the app to be responsive to change and adaptable to expanding/changing technology sectors. Tell him how you've helped the business people create a business process model and engineered your software around that model so that they can be clear when they talk about changes and you'll know what the impact ot the system is going to be. Tell him how you've architected your software in terms of simple, consistent components, so that when a change request comes in you can give me a list of components to be changed or added and have a real idea of the cost of that change, not a shot in the dark that's going to blow the budget because you missed half the work.
Programmers, those guys who sit and complain about requirements, bang out something at the last minute that hamstrings them for the next round, and prop themselves up for saving the day when in reality they've missed the bigger mark altogether, are in generall getting what they're worth.
Responsible software developers, those who know what is important to their organizations future and know how to make their software reflect that, are getting much more, and are in much bigger demand.
I'm pulling in $50/hr and doing about 45-50 hours a week. I've got a degree in Comp. Sci. and have 10+ years of corporate experience. I'm a contractor for a firm who's billing me at $75/hr, but that ratio is about to change. More's coming my way.
My success is coming from the fact that I can make the organizations I go into better able to be successful software shops. I went in as a senior general developer type. In the last year I've done very little real develoment. Instead, I've invented a new software document management system for the client. I've helped them figure out why they can't get software out the door, and why what they do get released is failing. Now I'm helping them kick off a multi-year re-architecture project for their entier hiring system. It's NOT because I'm a genius Java developer. I'm not. It's because I've found the principles behind software value. Simple, structured, flexible.
If you want to make money in this business, learn to do MORE than program and bitch about poor requirements. Learn how to make your organization better. Yes, they can indeed find good programmers for less money. So make yourself more valuable than Joe Programmer. Learn how to be responsible to your organization. Learn what it takes to make long-term value in your software, not the latest whiz-bang that's going to flip the next pore sod's wig when he has to figure it out. Learn how to deliver faster code that's more solid and easy to understand. And then learn how to teach others to do it. If you can do that, there will be a line outside your cubicle of people wanting you to work for them.
If you can't do that, either your days or numbered or you're setting your earningsceiling is pretty low. You're a commodity, and not a popular one.
There's a risk assessment tool that has a x-y graph. One axis is probability, the other is consequence. Going up the diagonal has high probability and high consequence. AS population grows we're putting more poeple along that axis. Not only are we putting communities where they're more liekly to have trouble, we're putting htem in places where the consequences are going to be more grave.
Rather than giving them just a budget, set some baseline technology objectives for the firm and use them to guide spending. Things like, "No front-line PCs over 2 years old." "No piece of equipment costing more than 30% of replacement cost to keep running." "No LAN speed less than 100Mb/s in the infrastructure." "No piece of enterprise software more than 1 major revision behind current."
These things will be guidelines that will let you count hte cost to get to the standard, and give guidelines on future spending as well.
Documents rot because no one USES the documents. I'm in the middle of a situation for my client where their ability to make code corrections or enhancements is compromized by the complexity (unnecessary) of the code and the loss of justification for why it is that way. So now they've asked me to help them dig out. One of the most common questions is, "Who's going to maintain all this documentation?"
My answer is that there is never a reason to MAINTAIN documentation. If you have to maintain it, throw it away. But if you're going to USE the documentation as part of your problem solving and day-to-day routine you'll be developing it just as much as you are your code. An analyst or system architect should express teh solution in the documentation, or more accurately the model. They hand off hte task and the solution in the documentation to the developer. They use the documentation justify and guide what they're doing. It has to be part of how you work.
See my earlier post about a design documentation philosophy. Your maintained model should be just enough to springboard any decision making about your system. Then work out from there into specifics about your task at hand. Start from your accurate baseline model. Build the new one from the current implementation. Validate that with the business peo ple to make sure it's correct, and make your design and implementation decisions. Do the work. When you're done you can throw that away because the task for which it was created is completed.
Like I said before, the purpose of Analysis, design, and documentation is to improve the probability that any development activity is successful. Do enough to achieve that and no more. Doing less is assuming unnecessary risk. Doing more is wasteful.
You can't ask for a good "design document". No single document is going to be sufficient for transfering design knowledge to every developer and analyst on a system. You need to have a good design documentation PHILOSOPHY.
I've been an analyst and coder and now system architect on a number of systems. My philosophy is to create a baseline system model that is the starting point of every discussion about the system. It is generally not detailed enough to answer any question about the system, but the important point is that IT IS ALWAYS ACCURATE! This model is the starting point of every discussion. We then look at the decisions being made and we start on a more detailed model that is tailored to those. That model -- diagrams, text, etc. -- is generally not proper for any other decisions because it's not focused for any other decisions. You have to do it again for every significant decision making session. That may seem like waste, but there are two important points.
First, we ALWAYS start from an accurate model. Any decision made from an inaccurate model may be inaccurate, and that means improper design, coding, testing, and delivery. In other words, defects. If your baseline model is not accurate you've changed underlying business objectives. That means you have a LOT of work to do. It should scare people when your baseline model becomes innacurate.
Second, we deal only with the information that is important for our current decisions. We have an accurate picture without distractions from extra information, too much detail, etc. We all know we can't maintain a detailed model. Software changes too frequently and deadlines don't let us spend the time we might need to maintain a fully detailed model. And we most of the time won't need a fully detailed model, just enough to make the decisions at hand. So don't try. Keep just enough to start from and go just far enough as required when you need to.
So, in short, develop a system model that has enough detail to springboard your development process, but not so detailed that it's hard to maintain and that it carries baggage to discussions that doesn't need to be there. This model will become the paper that everyone recognizes and everyone carries around to meetings. When that paper is insufficient for your decision making, let your analyst or system architect work with you to get you a more detailed model. When you're done, throw that one away because it'll probably be obsolete by the time you're done with your coding anyway. It certainly won't be pertinent to your next decision making and design activity unless you screw up the one that brought it about.
No methodology will tell you to do it this way. But then, I've never seen any named methodology ever executed to its fullest. No one can afford to do it.
The point of analysis, design, and documentation is to improve the probability that any development task will be successful. Out of the box, no methodology can guarantee that. But, if you approach analysis, design, and documentation with this as your objective -- making development successful -- you can use any methodology you want and adapt it as necessary. If you know your business people, your developers, and your processes you can take any methodology as far as it needs to go to improve that probability of success.
The fact that this can even be entertained as a rational suggestion is all the evidence necessary to conclude that the software industry is not about providing long term viable solutions to real business problems.
Robust, maintainable, well-behaved software that will stand the tests of time and budget CANNOT be arrived at by a PROGRAMMER. A PROGRAMMER will not acknowledge that there are more meaningful measures of design value than a nice algorithm or the latest industry buzz words.
We've done it for years. Forward your cell phone to whomever you wish to call, and then call your cell phone. We did this all through college to get free long distance. The call from local land line to local cell was free, no cell minutes used since the phone was never activated.
But then the rules may have changed since those years. And now I'm a successful adult who doesn't care that I have a $250 a month cumulative phone bill.
People are on good behavior first out of hte gate. Then, when they're more comfortable with those around them, after usually 3-5 months into the school year, they start taking what they like. Don't fall into the trap of trusting those you've made your friends in the first of the year. One of them will screw you somehow.
Java made it's way into the web paradigm. In the last 6 years I've never seen a web or any Java application taken nearly as seriously as anything I've been asked to do in C/C++. They just don't expect you to work as hard in the Java world. Anyone can do it, so it must be easy. If you're working hard at it you must suck.