1. If you don't know where you're going, you'll never get there.
In software, this means start with the Final Test (which is often called the Customer Acceptance Test, or the QA Pre-Ship Test, or whatever).
Until that test has been written and approved, don't even start the design. Write no code.
2. Find the hard problems.
This is part of that ugly stuff: Gathering Specs and Requirements (they are different, you know). Requirements Analysis. Initial design (only the broad strokes).
When you start finding "tough" problems, assign those to rapid prototyping efforts while the rest of the design proceeds in parallel.
3. Throw away ALL code that is written without a proper design to guide it.
That means ALL Rapid Prototyping code. For those hard problems, once you find a solution, immediately reverse engineer the design from it, and DISCARD THAT CODE!
4. A good design will allow even newbies to do 99% of the code.
It cannot be stressed enough: A good design saves time, money, frustration, problems and every other pitfall in the code development process. It isn't a "silver bullet", but it is the closest thing we have to one.
I had to prove this over a DECADE ago on two projects that were over budget and behind schedule almost from the start. On both projects I literally hired high school students and college freshmen to write the code. My job was to finish the design and test the code my programmers produced. They succeeded in spades.
5. Shit happens.
Features creep, budgets and schedules shrink, people come and go. Shit happens. If you are EVER surprised by this, you are either in the wrong profession, or are living with your head in the ground.
The weakest parts (greatest risks) of ANY project can often be identified well in advance, and must be closely monitored. Having "a" solution for each of your problems is seldom enough: Your highest risk areas need MULTIPLE solutions, so a fall-back is available when the primary fails.
6. Multiple perspectives are mandatory.
Seeing things just one way limits you to a black and white world, to travel along a single line. A second perspective gives you the freedom of a 2-dimensional plane. With a third perspective, it becomes possible to circumvent almost any obstruction.
What am I talking about? Simply this: Seek and understand the perspectives of others, especially those that differ markedly from your own. Understand them to the point that you can literally see them through their eyes, and argue their position for them (without playing Devil's Advocate).
Perspective allows you to push your horizon (your known limits) further away. Which in turn means you can see and react to problems far earlier.
While it is important for teams to agree on the direction to pursue, it is important to acknowledge that this is NEVER the "only" directiion available. I would recommend NEVER making a decision until at least two or three alternatives are available. This is especially true for the "easy" or "obvious" choices.
Sometimes, radical improvement and innovation demand bypassing the "easy" and "obvious". Unless you look for alternatives, you'll never find them. And you will repeat the same mistakes over and over (but in different ways).
Which is why, oddly enough, I seldom re-use code that I or my teams have written. By approaching things from a new perspective, I find old code always looks broken, no matter how good it looked at the start.
I should mention I have spent the last 20 years creating real-time embedded systems, often for safety-critical applications (such as nuclear power plants). Much of the above may not apply to a Web page or a Java applet, though I suspect it will apply quite well.
Ok, just one more:
7. The best tools are inside your head.
At all costs, avoid dependencies on any specific set of tools. Be flexible enough, and knowledgeable enough, to make effective use of whatever tools are available. Be willing to use them in ways their creators may have never imagined. (I once used an FPGA hardware simulation tool to help design and debug high-speed complex state machines.)
If a project is fighting about the tools to use, it may already be a lost cause. Tools are important, even vital, to the software development process. But no single tool or set of tools will turn a bad programmer into a good one, or allow incompetent managers to magically become competent.
A well trained and capable brain is worth more than any pile of tools. And a really good project team can succeed with little more than a text editor and a white board.
In a company WITHOUT an engineering department, the CTO supports and/or manages all the technology-related decisions within the company and coordinates technology issues with all outside entities.
However, when a company has an engineering department (that is, the company makes and/or sells products that contain hardware and/or software), the CTO is responsible for all technology that engineering is NOT responsible for. This generally includes things like infrastructure (phones, LAN, etc.) and the services provided by and on top of that infrastructure.
The CIO is responsible for INFORMATION, no matter if it is in digital form or not. He is expected to work closely with QA (especially if the company is ISO-9000 certified), Finance, Sales and Marketing, to ensure their communication and reports are accurate, timely and comprehensive.
To put it another way, the CIO is the keeper of all the "Business Processes" the company uses to do whatever it is that it does. The CIO will seldom create or mandate any process, but he will be responsible for evaluating, implementing and monitoring the services and tools needed to implement all such processes, usually at the behest of other corporate officers or board members.
Thus, the CIO will have strategic importance at the corporate level. In a sense, he has to know just what the company can or can't do, why or why not, and what it will take to make changes. He will consult on the changes, but will generally follow the direction of the CEO/COO and the company's Board of Directors.
The CTO is somewhat less strategic: He typically is responsible for providing the technical services needed to implement the technical portions of the processes the CIO is responsible for. The CTO is also responsible for having the "Big Picture" of all technology, both new and emerging, that has the potential to help or harm the company. In this sense he is also strategic: His advice and recommendations on technology issues affecting the company must be the best available.
Corporate officer titles are NOT job titles! They are a very different thing, in the legal sense. Corporate Officers are typically employees, with employee positions (President, Vice President, etc.), though Corporate Officers may also be drawn from members of the corporate Board of Directors. They are always named and confirmed by the corporate Board of Directors.
A Corporate Officer bears responsibility far beyond that of an employee: He is considered to be legally RESPONSIBLE for the behavior of the company, and the signature of a corporate officer is often required when certain commitments are being made or negotiated. For example, a Corporate Officer (employee or not) must sign most corporate SEC and IRS filings.
Now let's take another look at CIO and CTO: They are NOT just "managers" of technology and information: They are responsible for charting and maintaining the company's course, and the strategies related to following that course, within their domains of responsibility.
The existence of the CIO and CTO titles is direct proof of the importance of information and technology to modern business: It is now strategic, and worthy of far more attention than a CEO or COO alone can provide.
First, an ordered series of words from our local deconstructivist:
1. All Software that is Free (per the FSF) is also Open.
2. All Open software IS NOT Free! (The Open Source Movement accepts some licences that the FSF views as "non-free".)
3. All "Closed" (non-free) software programs are the Tools of Satan. (A somewhat loose paraphrase of RMS and the FSF.)
4. NDAs (Non-Disclosure Agreements) are the very Words of Satan. Signing an NDA is equivalent to entering into a pact with Satan.
5. The "One True Path" between the worlds of Free and Closed software is Reverse Engineering. Those platforms for which the One True Path of Reverse Engineering does not exist (in any practical manner), then that entire platform must be Banished!
6. However, when a thin software layer may be created that provides the means to convert a Closed platform to a Free platform, then it MAY be permissible to Dance with the Devil, for the express purpose of making that thin layer.
Note: Any person performing Step 6 WILL NOT be granted a dispensation: They will still Rot In Hell, since they did Sign the Devil's Paper.
However, if this saves the Free souls of legions of programmers, and if it also Royally Pisses-Off the particular Satan involved, then, well...
It May Be OK.
Slashdot Mirror
Transmeta is placing one hand below the low-end (embedded), and the other above the high-end (servers).
Then it will clap!
Let's break this topic WAY down:
1. If you don't know where you're going, you'll never get there.
In software, this means start with the Final Test (which is often called the Customer Acceptance Test, or the QA Pre-Ship Test, or whatever).
Until that test has been written and approved, don't even start the design. Write no code.
2. Find the hard problems.
This is part of that ugly stuff: Gathering Specs and Requirements (they are different, you know). Requirements Analysis. Initial design (only the broad strokes).
When you start finding "tough" problems, assign those to rapid prototyping efforts while the rest of the design proceeds in parallel.
3. Throw away ALL code that is written without a proper design to guide it.
That means ALL Rapid Prototyping code. For those hard problems, once you find a solution, immediately reverse engineer the design from it, and DISCARD THAT CODE!
4. A good design will allow even newbies to do 99% of the code.
It cannot be stressed enough: A good design saves time, money, frustration, problems and every other pitfall in the code development process. It isn't a "silver bullet", but it is the closest thing we have to one.
I had to prove this over a DECADE ago on two projects that were over budget and behind schedule almost from the start. On both projects I literally hired high school students and college freshmen to write the code. My job was to finish the design and test the code my programmers produced. They succeeded in spades.
5. Shit happens.
Features creep, budgets and schedules shrink, people come and go. Shit happens. If you are EVER surprised by this, you are either in the wrong profession, or are living with your head in the ground.
The weakest parts (greatest risks) of ANY project can often be identified well in advance, and must be closely monitored. Having "a" solution for each of your problems is seldom enough: Your highest risk areas need MULTIPLE solutions, so a fall-back is available when the primary fails.
6. Multiple perspectives are mandatory.
Seeing things just one way limits you to a black and white world, to travel along a single line. A second perspective gives you the freedom of a 2-dimensional plane. With a third perspective, it becomes possible to circumvent almost any obstruction.
What am I talking about? Simply this: Seek and understand the perspectives of others, especially those that differ markedly from your own. Understand them to the point that you can literally see them through their eyes, and argue their position for them (without playing Devil's Advocate).
Perspective allows you to push your horizon (your known limits) further away. Which in turn means you can see and react to problems far earlier.
While it is important for teams to agree on the direction to pursue, it is important to acknowledge that this is NEVER the "only" directiion available. I would recommend NEVER making a decision until at least two or three alternatives are available. This is especially true for the "easy" or "obvious" choices.
Sometimes, radical improvement and innovation demand bypassing the "easy" and "obvious". Unless you look for alternatives, you'll never find them. And you will repeat the same mistakes over and over (but in different ways).
Which is why, oddly enough, I seldom re-use code that I or my teams have written. By approaching things from a new perspective, I find old code always looks broken, no matter how good it looked at the start.
I should mention I have spent the last 20 years creating real-time embedded systems, often for safety-critical applications (such as nuclear power plants). Much of the above may not apply to a Web page or a Java applet, though I suspect it will apply quite well.
Ok, just one more:
7. The best tools are inside your head.
At all costs, avoid dependencies on any specific set of tools. Be flexible enough, and knowledgeable enough, to make effective use of whatever tools are available. Be willing to use them in ways their creators may have never imagined. (I once used an FPGA hardware simulation tool to help design and debug high-speed complex state machines.)
If a project is fighting about the tools to use, it may already be a lost cause. Tools are important, even vital, to the software development process. But no single tool or set of tools will turn a bad programmer into a good one, or allow incompetent managers to magically become competent.
A well trained and capable brain is worth more than any pile of tools. And a really good project team can succeed with little more than a text editor and a white board.
I'm done now.
Well, yes, but, allow me to redefine:
In a company WITHOUT an engineering department, the CTO supports and/or manages all the technology-related decisions within the company and coordinates technology issues with all outside entities.
However, when a company has an engineering department (that is, the company makes and/or sells products that contain hardware and/or software), the CTO is responsible for all technology that engineering is NOT responsible for. This generally includes things like infrastructure (phones, LAN, etc.) and the services provided by and on top of that infrastructure.
The CIO is responsible for INFORMATION, no matter if it is in digital form or not. He is expected to work closely with QA (especially if the company is ISO-9000 certified), Finance, Sales and Marketing, to ensure their communication and reports are accurate, timely and comprehensive.
To put it another way, the CIO is the keeper of all the "Business Processes" the company uses to do whatever it is that it does. The CIO will seldom create or mandate any process, but he will be responsible for evaluating, implementing and monitoring the services and tools needed to implement all such processes, usually at the behest of other corporate officers or board members.
Thus, the CIO will have strategic importance at the corporate level. In a sense, he has to know just what the company can or can't do, why or why not, and what it will take to make changes. He will consult on the changes, but will generally follow the direction of the CEO/COO and the company's Board of Directors.
The CTO is somewhat less strategic: He typically is responsible for providing the technical services needed to implement the technical portions of the processes the CIO is responsible for. The CTO is also responsible for having the "Big Picture" of all technology, both new and emerging, that has the potential to help or harm the company. In this sense he is also strategic: His advice and recommendations on technology issues affecting the company must be the best available.
Corporate officer titles are NOT job titles! They are a very different thing, in the legal sense. Corporate Officers are typically employees, with employee positions (President, Vice President, etc.), though Corporate Officers may also be drawn from members of the corporate Board of Directors. They are always named and confirmed by the corporate Board of Directors.
A Corporate Officer bears responsibility far beyond that of an employee: He is considered to be legally RESPONSIBLE for the behavior of the company, and the signature of a corporate officer is often required when certain commitments are being made or negotiated. For example, a Corporate Officer (employee or not) must sign most corporate SEC and IRS filings.
Now let's take another look at CIO and CTO: They are NOT just "managers" of technology and information: They are responsible for charting and maintaining the company's course, and the strategies related to following that course, within their domains of responsibility.
The existence of the CIO and CTO titles is direct proof of the importance of information and technology to modern business: It is now strategic, and worthy of far more attention than a CEO or COO alone can provide.
First, an ordered series of words from our local deconstructivist: 1. All Software that is Free (per the FSF) is also Open. 2. All Open software IS NOT Free! (The Open Source Movement accepts some licences that the FSF views as "non-free".) 3. All "Closed" (non-free) software programs are the Tools of Satan. (A somewhat loose paraphrase of RMS and the FSF.) 4. NDAs (Non-Disclosure Agreements) are the very Words of Satan. Signing an NDA is equivalent to entering into a pact with Satan. 5. The "One True Path" between the worlds of Free and Closed software is Reverse Engineering. Those platforms for which the One True Path of Reverse Engineering does not exist (in any practical manner), then that entire platform must be Banished! 6. However, when a thin software layer may be created that provides the means to convert a Closed platform to a Free platform, then it MAY be permissible to Dance with the Devil, for the express purpose of making that thin layer. Note: Any person performing Step 6 WILL NOT be granted a dispensation: They will still Rot In Hell, since they did Sign the Devil's Paper. However, if this saves the Free souls of legions of programmers, and if it also Royally Pisses-Off the particular Satan involved, then, well... It May Be OK.
Go here to see cameras capable of 20,000 fps, and others with up to 2k by 2k pixel resolution.