Well, dugan, I think that all of us are easily well-experienced enough to mutually understand where these boundaries properly lie, within the auspices of good and balanced engineering. "This isn't our first rodeo™, you and I or any-of-us." (We are not opponents ... yea, we are colleagues.)

"Yes, the cycles are very long." And, since they are sometimes longer than the business-cycles that they are intended to serve, a breakdown of the development process into a set of shorter therefore individually achievable milestones is usually necessary. But, each of those milestones/goals (call them whatever you please ...) must, in and of themselves, be definite ... and they must fit cleanly within the definite goals of the greater project itself.

In this way, of course, we're really trying to approximate the human-natural flexibility of a "human" project ... of a project that's being carried-out by people, not by computers ... within the very-harsh limitations of a "1-or-0" computing machine.

In this "oh-so binary light," while there is certainly nothing wrong with things like Agile in theory, there are very-often rather serious problems with it in practice. Even though you don't actually know what is to be done yet, the amount of work that you perceive to be left to be done prompts you to move forward anyway. Trouble is, the current embodiments of "Agile" theory do not ... at least, as far as I have ever been able to discern ... distinguish between "high-risk" things that "the team could be working on 'anyway'," and "low-risk" ones. (And furthermore, there seems as-yet to be very little consideration to the question of risk-assessment ... i.e. "how do you / does the team ... actually know what the risk is, anyway?" "Hard" vs. "Easy" is not "Risk.")

It's a hard problem ... and, one that all of us (old hands ...) know way too much about. Every "methodology," including but not limited to Agile, is certainly put forth with the very best of thought, experience, and intentions. Nevertheless, the problem remains hard.

My key objection to "Agile," at this point in its definition, is that ...

• At every point, every day, any-and-every Team must make a decision of "what to work on today." Yes, they literally cannot wait for decisions to be made, because some of those decisions take a long time to make and are made by many layers of people.
• Some of those decisions are "low-risk" and "not very pervasive," while others are opposite.
• Sometimes the Team runs out of conservative low-risk options (even when it is able to reliably tell the difference ...), and must make a decision anyway. And, sometimes, the Team has multiple options available and either does not know which one to choose or does not choose wisely.
• There's a strong human incentive to look busy, and also to avoid acknowledging that you don't know what to do.
• "The Agile Theory" does not sufficiently consider this – nor do many other 'methodologies.' ("They don't-answer the question, then blame us for making the wrong decision.")

And, by pointing out this (IMHO) shortcoming of the theory, I am n-o-t faulting it for trying!!

A further objection that I have to, well, "'methodologies' in general," is also, I think, a practical one: that they ratify "indecision," or perhaps, "whatever decision turns-out to have been made." If you do choose "to write code" when the ruling-definition and the ruling-constraints of "that particular piece of code" are not yet sufficiently known for you to have justifiably done it, then you are most-likely wasting your <customer's | employer's> money, and nothing more.

Yes, "we are paid to work," and yes, "there is a amount of work yet to do." But we nevertheless must be more-selective than we usually are about what to do and when to do it ... and we must elevate the need for both "hard specification" and "brutal testing" far more than we ordinarily do. In this regard, IMHO, "'methodology' theories" are woefully simplistic. "Nice theory, but ..."

Thankful to you for the constructive follow up.
I'll go through those softwares soon.

I wonder BTW how did you manage to remember this two year old thread!

I'm good at that stuff.

And LQ is also a hobby of mine.

I can see that it's an old thread, looks like the OP is still paying attention, good points by dugan and sundialsvcs. I especially like the google code review story. Yes, it's interesting psychology that someone will write more appropriate and cleaner code if they know people are going to read it.

I've been on both sides of raw code exposure; which is to say that I've bought source stacks and written source stacks for sale. That is one of the ultimate things to consider, because as a purchaser you need to be able to rapidly compile and utilize this expensive thing you bought, and benefit from it soon. Likely also because you're the engineer telling your management that this will save you time. In the other direction, you need to provide a good product and well documented, well designed, well tested enough so that your support requirements are trivial. The experiences there which were most helpful were test harnesses, emulators, simulators, all of the above which were provided in order for the seller to rapidly indicate to the buyer that the integrity of what they sold was good. Further, levels of diagnostics whether they be logs, log levels, as well as interim output files and included offline utilities are excellent assistance to be able to provide for tuning of a complex solution with coherence as well as uniformity where all your customers will give you basically "your" output files and logs, but from their system and you'll be able to take those files and run them through your utilities, send that back to them and identify the exact problems, be they your design limitations, design flaws, or their use case problem.

Also organization is paramount and documentation does not have to be extensive; however code structure and conventions need to be uniform across your entire release and it's helpful if those conventions match across various product codes, so that when they buy one stack, and then choose to buy another, they pretty much understand the second one rapidly because they have experience with the first one.

If you take the Linux kernel for example. There are a lot of files, however the architecture is explain-able there is a breakdown of the functional blocks of kernel source. So similarly if you create a complex product, you follow guidelines to segment your software in similar fashion.

As far as the more formal methods. Yes, long, long ago a company I was with subscribed to the Software Engineer Institute (SEI) standard, Levels 1 through 5 I believe. That involved Functional Design, reviews, Interface Design, reviews, Architecture design, review, test design, review, high level design, low level design, coding, all accompanied by peer/team reviews, down to code walk throughs, unit testing, and tracking of defects and flaws. I forget the actual terms, but one meant "a problem at 'this' level, instituted by misunderstanding or just downright error" and the other meant, "a problem at a previous level which propagated, and we just happened to discover it now". Our problem at the time was once we had feature creep the whole thing became hugely un-manageable. Engineering had put in soooo much time to write-review-write each level, jumped down everyone's throat to 'catch' everyone's bad habits; we were out of horsepower when it became time to iterate and do updates. As a result, everything in documentation became out of date, code got rewritten really fast due to time crunch an we shipped xx weeks late, but it was deemed a success because before products were months late versus weeks.

At one other point I got involved with critical software for systems which could only allow for single faults, by their definition. It used the DO-178 documentation system, DOORS, it's been updated to something else. That was interesting, I entered in the middle, and everyone from planning, to design, and test lived in DO-178. Requirements were updated, causing changes to ripple into implementations and into test. Sometimes it turned out that the change in requirement had no impact on the implementation, but impacted test in that the test had to specifically be designed to validate that the requirement was satisfied. It was clearly necessary whereas this was for things that either had to work, or had to fail in a consistent manner to allow a secondary system take over. What I learned from that is that it's the same as things like the space shuttle. Defense in depth. You can design as fault tolerant of a computer as you want, but ultimately the systems persons are going to say, "Well it can fail ... so I want two of them running independently and located in different places." But to apply that analogy differently, within each system, there may be xx number of drivers, applications, or sections of the OS itself. Therefore you test each independently, specify how it interacts with external things and strive to test all possible interactions as much as you can to validate that you've tested all possible points of failure and satisfied the functional specifications. The good functional specification also indicates what faults the system must deal with.

1 members found this post helpful.

Excellent points here, RT.

The particular line-of-work that I have somehow glommed onto is the resuscitation and repurposing of failed web-apps that are usually 5-10 years old (but some much younger). So, what I customarily see are ... "big, reeking, sacks of .") And sometimes I have to play the part of the emergency-room doctor who has to walk out into the family-lobby with a very long look on his face, and a shovel in his hand.

The problem is that the code-quality simply isn't there. And, there is no internal consistency with regards to what this application does attempted to do, nor where and when it does it. Therefore, I do see first-hand "the downsides of Agile/Scrum in actual practice." These programs, into which so much money has already been poured wasted, would require still-more money to be poured wasted into a big, dark hole before there would be any hope of salvaging a return-on-investment (ROI) from it.

Systems like you describe, with regard do DO-178 and so-forth, even though they might emerge "weeks" or even "months late," presumably have a high probability of being solid in actual service, such that their probability of error/failure is low, and the probability that any such errors/failures would be detected and diagnosed (and diagnosable) would be high. Therefore, these systems have a reasonable chance of being "stable" so as to produce a long-standing service life. Most of the corpses applications that I encounter emphatically don't, and these certainly are not the work of amateurs. It's unfortunate for a ship to be "late," yes, as long as it does make it into port and stay there without leaking bunker-oil everywhere.

The complaint that usually brings us to a new engagement is a relatively simple one: the software isn't stable, it isn't finished, the team that remains on the project has clearly lost its way, and yet there is a constant flurry of sticky-notes and "activity" (sic ...), and the $100+ per-hour invoices are still coming.

Well, dontcha know ... "C-team" folks do sometimes have a very candid way of saying certain things. One CEO, who was ex-Navy, matter-of-factly and very-calmly told me: "either we are going to land this bird right now, or we are going to shoot it out of the sky."

Uh, huh. A few methodical weeks later ... "Bang!!" (And, to this former senior-officer's great credit, no "heads rolled." )

Whatever the work-process was, or was supposed to be (and usually lately it is "Agile" performed by serious teams), the outcome did not meet the requirements of the business, the project, or the software itself. So, even though we may have made certain improvements to our approaches to software, we are still a long way from where we need to be. (And, as this CEO/officer did, I do not blame the people, nor necessarily, the intended process. This is a damn-difficult thing that we are doing. But, we've still got to get a whole lot better at it.)

I agree Sundial. Two things come to mind with your last notes there. (1) Yes it is very common; individual contractor, contract company, or even within a company where software re-use is done, also true is the case where an existing project is partially complete, a complete mess, but handed to you as something you need to just polish up and finish. (2) A great, great deal of individuals in project management, technical management, implementation, basically all up and down the delivery ladder; don't know how or when to properly draw the line on a product release point. And these two items center around perception and effective decision making are artistry where the better executors at it shine, and hopefully don't get squashed by higher powers.

Dealing with issues surrounding perception at least you have the powers of analysis and technical data which you can organize and bring to bear to make cases for not sidestepping important parts of efforts.

Execution of a point of closure is easier if it's just you, we all can be guilty of temporizing to attain perfection. With a vast team it's a lot more difficult to get common agreement that a release point has been reached.