You forgot your forth, and probably decisive, advantage: You knew all aspects of the task.
I commented on it in my first post (and I think Fred hinted along the same lines in one of his early posts), that one person must be able to grasp the whole problem. You saw the potential trouble spots beforehand and avoided them. The most efficient way to recover from a problem is to avoid the problem in the first place. You knew the hardware/software high/low conventions and so on. The other team had to discover all that.
Of course, you had even more advantages in that you had designed the rest of the system, so let's say you saved a week or so of finding, reading and understanding the system spec.
-- % Randy Yates % "The dreamer, the unwoken fool - %% Fuquay-Varina, NC % in dreams, no pain will kiss the brow..." %%% 919-577-9882 % %%%% % 'Eldorado Overture', *Eldorado*, ELO
Well, you didn't have a working model in the context of your application. But you also didn't *prove* that cracking would occur did you? (If you did then OK - bear with me; I'm not suggesting that you didn't have a valid concern).
What if it had been built for NJ and no failure occurred? And subsequently the worry came up? Should you change the implementation or not? Your example re: California is perfect! The worry was apparently sufficiently justified that taking the nuts off in California would have been the smart thing to do.
A lot depends on the change that's contemplated. I once had a job solving problems on a system that was in production. The idea was to solve the problem without introducing any additional parts. It was a great challenge and fun to solve the problems with that constraint. Very much like removing the nuts. Mind you, the solutions were changes - but ones that had been asked for.
So, if all you had to do was remove some redundant nuts in order to make the design "better" then by all means. These notions are more guidelines than hard and fast rules. When the notions are stated in "shorthand" then maybe they sound stricter. If you *must* make a change then who could argue? We have not (thank goodness?) talked about change control - which is often more about configuration management but can also be about making the decision to change or not to change in a formalized manner. The idea about design freeze is to enable getting into production without ruining all the testing that has already been done. It's also about getting rid of the crazy "new ideas" that some folks *never* stop coming up with, and curtailing those participants who can never make a decision, so that there can be a reasonable degree of stability. It's also about not paying for the changes (risk, time and money) unless it's necessary.
If you have always worked with sensible people who always made the right decisions and caused things to happen really well without a hitch then you might think others are a little crazy to suggest some structure. But, if you've worked with people who are always wanting to try the latest and greatest stuff because having fun is more important than getting out the product or if you've worked with people who can't make a decision or if you're working with people who would make an unnecessary change (because they had not weighed the cost and risk vs. the benefit - or because their assessment is different than yours) then you would see the value in some structure along those lines.
Sometimes "design freeze" is used to simply get people to make up their minds, finish their work, etc.
Software is *so* easy to change. How many times has someone broken the system with some little change? The software books are full of examples. Of course, many of those examples are to make a technical point. But the examples sure beg the question: "What if the change had not been made at all? Would it have mattered - i.e. would the system still have performed just fine?" That's more to the point. How many times did the change come up because the programmer thought: "Well, I just figured it might be easier to read the code if ...... "
I'm pretty sure we agree on most of this....
At the core this is more about decision making. Your folks decided to not make changes in California. Were they driven to that decision because they didn't want to spend the money? Or, were they driven to that decision by blind allegiance to a "freeze" kind of rule? I'll bet it's the former and, on a comparative basis, I agree with that being the driver even if we might disagree in hindsight (or in foresight) with the decision they made.
Rune, I'd rather argue about practical matters instead of definitions, so let me try it this way:
In my shop, unless I have to pass an audit, the products of all these activities are mostly code. At the level you're describing, most of this code is just interfaces, comments, and glue, but it is real code that becomes part of the project. After all, it is code that really defines the algorithms that get used, and the program organization, etc. The code will be documented with block diagrams, overviews, various bits of UML, etc., in order to communicate its gestalt more clearly, but most of the work here is code.
I know that a lot of process-oriented folks think that there should be a separate design phase that produces something other than code, but which is actually a lot like code. In my experience, this is a bad idea. Rather than turning much of the programming job into mere transcription, it's more efficient to write your original ideas directly in the target language. That way, your programmers can work on something more interesting, and you don't need to rely on their secretarial skills to transcribe your thoughts accurately. (Pssst. They don't *read* what you write. They just skim through it.)
I have a bit of trouble understanding what you mean by this. If you really mean "a pre-determined action", then I know there are places where programmers actually have jobs like this, but I swear that my shop will never be one of them. Have you seen "Metropolis?" If you just mean "fulfill some defined purpose", then you can see why I think that this is the same task as above, but on a smaller scale. The product of this activity is also code. It's just more isolated code that isn't reflected throughout the system like the overall architectural components are. The processes used for creating all this code, and the purpose of all this code, is essentially the same. In all cases, the coder is defining the structure and operation of software.
I know you may not agree with my way of thinking about this, so to see who is more practically correct, perhaps we should see if we can find some sort of phase transition near the middle of the software development process that would justify your assignment of different labels to the pre-transition and post-transition phases:
- Is there a point near the middle of development where schedules suddenly become firm? In my experience, no, there usually isn't. Certainty increases gradually and continually during development.
- Is there a point near the middle of development where feasibility suddenly becomes proven? I have found that doubts about feasibility can only be quelled by real implementations. It is a good idea to implement these questionable parts of a project early, but because these aren't usually isolated or architectural parts of the project, you can't just do them all first.
- Is there a point near the middle of development when you can validate all of your preceding assumptions with the customer? Again, in my experience, there is not. If customers could look at a project in progress and really determine whether or not it meets their needs, they wouldn't need you or me.
So, if you still think that there is a real, practical, division of development into design and implementation phases, then when, oh when, does it occur, and what are the practical consequences of reaching it?
Oh what bliss. A man who's free of inner conflicts. I often vigorously disagree with myself - especially when my tongue is saying "eat that" while my brain is saying "now, just how many kilos did the bathroom scales show the other day?" :-)
As America's great philsopher G.W. Bush so wisely said "I have opinions of my own, strong opinions, but I don't always agree with them." :-)
Before I write code, I want to know what it's supposed to do. When it's for a client, I want to be very sure that the client knows it's supposed to do. I did programming for hire for a time, sometimes moonlighting, and for a while as part of my only professional activity. I learned from other's bad experiences before I started to insist on a set of specifications that would allow the client to prove that I didn't finish the job, and allow me to prove that I did. Some clients didn't like to be pinned down, and if I liked the job I would help to write the document. I excepted as a requirements specification a users manual that explained how to use every feature and described everything that a user would see. If it was loose, I reserved (in writing) the right to fill in the details as I thought reasonable, and to charge extra for changes. It was a good policy, allowing me to keep friendships that I would otherwise have lost. Once, it sort of backfired.
A friend of a friend asked me to code a personality profile program he could use in his business. He had the algorithms and a general outline, but no details. I asked for a spec to work to, saying that a user manual would do. He said he'd get back to me when he was ready, we shook hands, and I didn't hear from him until I got a check in the mail, about a day's fee, a few months later. I phoned his office about the mistake and asked if I should return the check or tear it up. He phoned back about an hour later and told me that I had more than earned it.
He confessed that he had been frightened to put specs on paper because they might not be reasonable to meet. So every time he wrote a coherent subsection of the manual he coded it in BASIC to see if it was workable. Most of the time it was, and when it wasn't -- GWBASIC is not a good language for graphics -- he changed the manual. By the time he had the specification, he had a working program. The check was for teaching him how to get it right. I cashed it happily despite knowing that I had talked myself out of a job.
The design part consists of deciding what the used will see and what he must to. Coding comes after. Design can be a chapter at a time, or the whole manual, but at every point along the way, you need a direction.
Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
If you design a complex 10s Mgates system-on-chips where each of the
10s masks costs 100k$ and where each design iteration is many months long, you'll be killed if you come w/ your experimentation approach. I don't think it's trivial ; so I'll try to compete w/ Newton w/ my small capabilities.
Why not carefully think about your implementation of the requested features? Select the appropriate architecture from the very beginning (and regarding the penalty if you didn't choose the right architecture from the beginning, you should better carefully look at the features you're looking for and in which direction they can develop), identify the main technical risks and concentrate on a way to be sure that the architectural choices + the main functions will be validated during the first iteration and that all the debug functions are in place to identify most of the bugs.
W/ Mgates FPGA and ASIC, HW stuff is no longer trivial. The HDL productivity has only slightly improved while in the mean time the FPGA/ASIC density has drastically increased. HW is not SW. Any design/experiment/update approach only leads to loss of time (and therefore $).
So, you don't produce any models of the modules in your chips? You don't use any simulators to debug each modelled element of the design? You don't try to simulate the entire thing to the extent the available tools will permit?
I think perhaps you do. Clue: those models are prototypes, and those simulators are where you experiment with them. I really really doubt you'll get a big design right without using them effectively. Even if you can get the logic right at the first attempt, your timing constraints must be pretty loose if you don't need to try some experiments with simulators to check the critical paths are going to play nicely.
Chips tend to have clearer requirements than complete systems. Few complete systems of any complexity are implemented without changes in the requirements along the way. Attempts to resist such changes just increase the likelihood of the system being already obsolete, or just inappropriate, on completion. Experimental systems (either physical or simulations) available early are a powerful way to get the end users to really figure out what they want. Specification by simulation is the only way I've ever seen a spec produced that survived the implementation phase intact. It is still a strategy too rarely used, even though it was producing excellent results 20 years ago.
You write like you have a chip on your shoulder (pun partially intended) about software vs hardware work. You seem to assume I was writing from a software developer's point of view. If so, you were wrong. Most software developers generally don't have to worry too much about this stuff. With so many embedded systems now using flash, most software is fairly fluid even after the ship date. :-)
I know what you mean, although I don't have enough experience to actually fill in. My experience are with projects taking one or to people to code (the "one" being me) where somebody have some expectations to the program. I don't know how you think of it, but I prefer to spend a lot of the time talking with the customer so I know what he expects, and prehaps reaches an agreement on how to do things. When I know the "big picture", I may be able to prepare an extension later on, in a follow-up project, even if we are talking merely basic stuff at the first delivery.
That's usually why projects blow up, in my experience... the first, "naive" thoughts may have some essnce of usefulness in them, but usually I have to start over from scratch pretty soon, if I start out that way.
What is wrong with having the programmers chime in when discussing the overall project? Not necessarily with the customers, but at least in-house? With a bit of luck, they come up with some good ideas, and it might perhaps even generate a bit of interest with them.
I mean that once you sit down to actually write the code, you should be
very clear about what that code is supposed to do. I did not say that somebody *else* than yourself/the coder should come up with the plan, but the plan ought to be clear beforehand.
I haven't seen metropolis, but I get the general idea. I don't have much sympathy for that kind of places.
I am not sure we disagree, but I think we have slightly different experiences and because of that, different ways of working.
Sure. I still like to spend as much time as possible in the early phases, to try and get as much as "the big picture" as possible. Seeing the likely post-project extensions is an advantage, it may pay off to provide certain hooks and labels early on, that would otherwise require an extensive re-working.
Agreed. However, in my book that's R&D-type projects that must be treated somewhat differently. At least, the "real" project should pe preceeded by some sort of feasability study, or a termination clause should be included in the contract if such questions are known beforehand.
I have been involved in projects where that actually happened. True, not software projects, but data analysis pojects. The customer had an idea about how to make a measurement, but they did not know how to actually go through with it. From the customer's point of view, this was an R&D project. As far as I was concerned, there was no R&D involved, only using tried and tested techniques in a new setting. As we went through the project, there were frequent dicussions about "can we replicate the
analysis results from the lab in a real-life setting? Can we get the equipment to survive a real-life setting? Can we train production staff
to handle the equipment? Can we train analysts to include the data in their analysis?" If the answer to any of these questions was "no", the project was a "waste" of time and money, the equipment would not reach its intended production stage.
But we didn't know the answers until we tried. The customer knew all the constraints, I knew what the equipment needed to do. Sometimes we could sacrifice some "convenient" gadget in the analysis, others had to stay or the measuring device would not work. Sometimes we we could change or adjust the existing operation process, other times what we contemplated was a threat to the equpment we tried to make more reliable and efficient. It was a really interesting project.
If you understand me such that I split "design" and "implementation" into very separate phases, in time and perhaps even people, I have expressed myself poorly. I am thinking of "design" in terms of selecting algorithms, organization the activity/program and, well, think the task
through before taking any actions. It's the antithesis to the "make code now!" approach I have very poor experiences with.
There are usually several ways to get something done, one is usually more favourable than others. This may depend on the actual circumstances of the project. "Design" is about analysing the problem and selecting how to do things. It could be all those talks with the customer before the project actually takes place, or it could be the coder deciding whether to implement some function as a recursive call or some nested loop. Either one might get the job done right now, but "the big picture" might suggest that some task or extension becomes easier in the future, should particular method be chosen over the other.
That's great if you have the freedom to do it. I've never had that amount of freedom. There's nearly always been someone breathing down my neck wanting to me to communicate what's happening now, why it's happening, when the next thing is happening.
For me, the big up-front approach has never given me the ammunition to resolve those issues... it takes to long to "show" anything... and then, when you do have something to show, it comes all at once, so the neck-breathers ask "Why didn't you do that six months ago?!?!?!". The "trickle" approaches have allowed me time to set expectations (things happen, early on, but not necessarily at a blinding pace, but they keep happening).
:-) Definitely good advice. I just like arguing. :-)
I've thrown out a lot of early code because it led to unfortunate data structures or module interfaces. I'm not prescient enough to get those right most of the time on unfamiliar ground, and I know it. My approach is to write a quickie that covers most of the ground, try to use it, and learn a better way from it. It would be a waste to give it more features that what's needed for a shakedown, then I chuck it and start over. Many programmers I admire work that way.*
Sometimes, I just do that in my head. I've actually debugged assembly code by single-stepping it in my head as I drove home from work. I suppose I should have been elated at finding my bug, but it made me feel pretty stupid.
Throwing code away can be depressing if it was originally intended to be kept, but making it part of the planning process takes the sting out. Has there ever been a completed project that couldn't be improved by another go-round? A quickie prototype can capture most of the benefit of a second chance.
Jerry _________________________________
If the boss will insist that you flesh it out and keep it, do it in secret. At home on your own time if need be.
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Most large structures have expansion joints or are carefully designed not to need them. I considered the lack of them in the aerator supports do be a design oversight and our consulting engineers agreed.
Not every design flaw jumps up and bites. Carelessness doesn't always exact a price. (If it did, most of us would be sorely beaten.) Recall that we used a turnkey design. Our engineers adapted it to the soil conditions and supervised construction, but they didn't design it. The California plants were the responsibility of other owners. The design owner modified the plans that applied to new installations. Where we slipped pipe over the bolts (kept in place by a nut on the bit of thread that protruded) and enlarged the bolt holes, new installations used smooth instead of threaded anchor rods. I do not know the weather conditions before the California crack, but I was told that the damage saw not from an earthquake.
Removing the nuts allows the steel to contract. One must remove the pad between the steel and the concrete to allow the steel to expand. That's difficult without disassembling the aerator.
...
Yes.
See above. They weren't my folks. I don't know what the patent holder recommended, nor the process use for deciding by the several California owners.
"Freeze" is a bad word in the sewerage business. Requirements change as effluent limits are changed by government and communities grow. Our plant's sludge incineration system was designed when oil was cheap. The presses that separate sludge from water were inefficient but rugged and simple. The high water content of the "dried" sludge made continuous oil or natural-gas firing necessary to get the poor bugs to burn. (Have you ever held a handful of live bacteria? That's what sludge is.) Oil was expensive by the time the plant when into operation. Within a few years, we replaced the belt presses with more effective vacuum presses at no small cost. (An energy-conservation grant helped.) The sludge now burns on its own once the incinerators are up to temperature, but the presses stank up the whole operations building. So we rebuilt the air handling system, including scrubbers for the exhaust air so as not to gross out the neighbors. Then we ... It never ends. Although I'm no longer a commissioner, I'm still officially involved, mostly with odor control. The plant seems to be as much alive as the bacteria that make it work.
Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.