October 1, 2009 at 12:37 pm
The Waterfall approach: First hire an army of business analysts and project managers to full describe what will be built. Add some more people to do scheduling (Critical Path -style with Fragnets and everything!), reporting etc. Throw in a like-sized development team and oila! You can build a missle! It takes a cast of thousands and a budget to match.
The Let's-See-If-It-Sticks approach: Code, ask questions, do demo. Rinse and Repeat. Just don't do it on a fixed bid 😉
If you're building a vehicle for human space flight or a nuclear reactor, the first choice is more likely to yield fewer dead astronauts and giant holes in the ground where a city once stood.
Business problems are ususally not that complicated. The need for speed rules.
Having done both--neither is better, just appropriate.
October 1, 2009 at 1:11 pm
If you're building a vehicle for human space flight or a nuclear reactor, the first choice is more likely to yield fewer dead astronauts and giant holes in the ground where a city once stood.
Are you sure? Ironically, the astronauts got to the moon thanks to Charles Moore's simple and lightweight Forth-based software. NASA used a lot of his applications. He is the most eloquent advocate of the 'Get something up and running quickly; evolve the solution' approach. Sometimes the biggest armies make the greatest collective mistakes.
Best wishes,
Phil Factor
October 1, 2009 at 2:07 pm
GSquared (10/1/2009)My own software career started out with an Access database, and it was junk. But it was better than what we had prior (which was post-it notes). Over the years, it kept getting better, and it ended up as something that was pretty darn good. It's been over two years since that software was in use, and I still get e-mails from former co-workers telling me they were spoiled by it.
Currently using Excel to do a job that our how-many-million-dollar software can't do. Ridikerous. Maintenance is annoying, but we'd be using pencil/paper/calculator without it, and with a much higher error rate.
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
October 1, 2009 at 2:15 pm
Phil Factor (10/1/2009)
If you're building a vehicle for human space flight or a nuclear reactor, the first choice is more likely to yield fewer dead astronauts and giant holes in the ground where a city once stood.
Are you sure? Ironically, the astronauts got to the moon thanks to Charles Moore's simple and lightweight Forth-based software. NASA used a lot of his applications. He is the most eloquent advocate of the 'Get something up and running quickly; evolve the solution' approach. Sometimes the biggest armies make the greatest collective mistakes.
Have to agree with Phil here, the guys who went to the moon or supported the crew were just crazy good and could do things like stay alive with duct tape, plastic bags and cardboard when the oxygen was leaking out of their ship.
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
October 1, 2009 at 4:53 pm
I'm with Phil. Get some initial requirements, get a prototype to the client and proceed from there. This definitely requires the KISS principle which a lot of developers seem to have problems with. I have been employed by my company specifically to build applications and databases for the various departments that need them. It works well here. I report to the COO but also liaise with IT. I have a good relationship with our IT department. This means that I am aware of the initiatives that IT introduce and they are aware of all the development I do. I help them vet off-the-shelf applications and administer the SQL Servers as they don't have a DBA on staff and I have some DBA skills (growing with my participation here I must say!). There is still some ad hoc development but much less than in most companies.
I have had to deal with apps built by others, both developers and users, and repair the mess. The worst was from an engineer who thought he could develop. ARGH! That code still makes me shudder!
Cheers,
Nicole Bowman
Nothing is forever.
October 1, 2009 at 8:23 pm
Phil Factor (10/1/2009)Are you sure? Ironically, the astronauts got to the moon thanks to Charles Moore's simple and lightweight Forth-based software. NASA used a lot of his applications. He is the most eloquent advocate of the 'Get something up and running quickly; evolve the solution' approach. Sometimes the biggest armies make the greatest collective mistakes.
Quite sure Doctor Phil 😉 Believe it or not I actually worked at the Kennedy Space Center and saw both approaches--more of the Waterfall than the Moore approach mainly due to government procurement regulations and such.
In my later career life I also saw the garbage people would try to substitute for planning, documentation and design.
I'd argue that the lack of discipline kills far more projects than over specification. Overpromise, under-deliver...seen a lot of that and I'd bet you have too.
I find the balance between the two works generally. My projects aren't large by NASA scale. I can get by with a reasonable amount of design -- just enough to get the main business rules right. After that why not go the Moore route?
October 2, 2009 at 3:17 am
Jeez, I've spent most of my career developing proper process and procedures to deliver quality software products as I had it beaten into me from day 1 that software engineering is somehow an inferior discipline because we don't document, we can't estimate or deliver something that works in time or budget. Now business is telling us they want it like the bad old days? Well I'll dust off my six shooters, don my 10 gallon hat and rejoin the ranks of the cowboy programmers. Yeehaaaahhh
No doubt in a few years people will be screaming about dodgy data, slow networks, flakey code etc..
October 2, 2009 at 3:40 am
jcrawf02 (10/1/2009)
Phil Factor (10/1/2009)
If you're building a vehicle for human space flight or a nuclear reactor, the first choice is more likely to yield fewer dead astronauts and giant holes in the ground where a city once stood.
Are you sure? Ironically, the astronauts got to the moon thanks to Charles Moore's simple and lightweight Forth-based software. NASA used a lot of his applications. He is the most eloquent advocate of the 'Get something up and running quickly; evolve the solution' approach. Sometimes the biggest armies make the greatest collective mistakes.
Have to agree with Phil here, the guys who went to the moon or supported the crew were just crazy good and could do things like stay alive with duct tape, plastic bags and cardboard when the oxygen was leaking out of their ship.
http://en.wikipedia.org/wiki/Apollo_1
"Apollo 1 is the official name that was retroactively assigned to the never-flown Apollo/Saturn 204 (AS-204) mission. Its command module (CM-012) was destroyed by fire during a test and training exercise on January 27, 1967 at Pad 34 (Launch Complex 34, Cape Canaveral, then known as Cape Kennedy) atop a Saturn IB rocket. The crew aboard were the astronauts selected for the first manned Apollo program mission: Command Pilot Virgil I. "Gus" Grissom, Senior Pilot Ed White and Pilot Roger B. Chaffee. All three died in the fire.
"Although the ignition source of the fire was never conclusively identified, the astronauts' deaths were attributed to a wide range of lethal design hazards in the early Apollo command module. Among these were the use of a high-pressure 100 percent-oxygen atmosphere for the test, wiring and plumbing flaws, flammable materials in the cockpit (such as Velcro), an inward-opening hatch that would not open in this kind of an emergency, and the flight suits worn by the astronauts."
What were you saying about going to the moon, simple and lightweight development, and fewer dead astronauts?
Now haere's an interesting comment on the Space Shuttle's redundant set plus backup flight system computer:
http://history.nasa.gov/computers/Ch4-4.html
"John R. Garman of the Johnson Space Center Spacecraft Software Division said that "we probably did more damage to the system as a whole by putting in the backup". He felt that the institution of the backup took much of the pressure off the developers of the primary system. No longer was their software solely responsible for survival of the crew. Also, integrating the priority-interrupt-driven operating system of the primary computers with the time-slice system of the backup caused compromises to be made in the primary."
The thing is, I try to do good work anyway. How much better a job would I do if, according to John Garman's idea of positive motivation, users of my program are gonna die if I left a bug in there? So, yeah, we could wire the user's keyboard directly to the wall electric outlet, complete the circuit by earthing the chair...
Anyway, didn't other astronauts have to keep switching their damn computers off and on to clear errors? Oh, here's John (Jack) Garman again, on Apollo 11:
http://en.wikipedia.org/wiki/Apollo_11#Descent
"Five minutes into the decent burn, and 6000 feet above the surface of the moon, the LM navigation and guidance computer distracted the crew with the first of several unexpected "1202" and "1201" program alarms. Inside Mission Control Center in Houston, Texas, computer engineer Jack Garman told guidance officer Steve Bales it was safe to continue the descent and this was relayed to the crew. The program alarms indicated "executive overflows", where the guidance computer could not complete all of its tasks in real time and had to postpone some of them. This was neither a computer error nor an astronaut error, but stemmed from a mistake in how the astronauts had been trained. Although unneeded for the landing, the rendezvous radar was intentionally turned on to make ready for a fast abort. Ground simulation setups had not foreseen that a fast stream of spurious interrupts from this radar could happen, depending upon how the hardware randomly powered up before the LM then began nearing the lunar surface: hence the computer had to deal with data from two radars, not the landing radar alone, which led to the overload."
So Neil Armstrong switched off his targeting computer and used the Force.
October 2, 2009 at 3:45 am
bob.willsie (10/1/2009)
I'll give you an example. Our company has an "IT Steering committee." It consists of top level executives and the IT department heads.When a suggestion was recently made to add end user department representatives the reply that came back, almost verbatim, was: "The purpose of the IT Steering Committee is for IT to tell the top level executives what IT is going to do. It is not intended to set policy or direction for IT." The response was provided by the head of IT on the IT controlled company web site.
So... the steering committee is for the IT department to steer the rest of the company?
I imagine they'd prefer people didn't express it like that?
October 2, 2009 at 6:12 am
Excellent observations Phil, and very right-on with the reality in most businesses.
I would also point out that the tools we use these days in software development, are directly contributing to the slowness of development. The entire concept of RAD (Rapid Application Development) has been killed by behemoths like .NET which was best described as something like "cleaning your fingernails with a backhoe". I fondly recall the years that we had numerous good development systems and languages that allowed quick and effective development of software. Now, there are only two real games in town, VB.NET and C# - these along with the way-too-vast .NET namespaces and over-done Visual Studio represent a giant leap backwards in Microsoft-centric development.
I still shake my head thinking that in the 80's I worked for the largest Facilities Management company in the world and in 42 days we developed a full blown support application. Now-a-days, the same project would take months.
RAD is dead, and Agile development is a great idea on paper, but I have yet to see it really work in the real business world as its laid out in theory. The problem lies in both the thinking, human nature, and the tools to get the job done.
In 1984, Steve Jobs released a commercial for the Mac showing hoardes of IT people all marching to the same lock-step. Jobs and the Mac were promising then to break people away from that. In the last decade, Microsoft has ensured that that vision, is the new reality.
October 2, 2009 at 6:13 am
"Apollo 1 is the official name that was retroactively assigned to the never-flown Apollo/Saturn 204 (AS-204) mission. Its command module (CM-012) was destroyed by fire during a test and training exercise on January 27, 1967 at Pad 34 (Launch Complex 34, Cape Canaveral, then known as Cape Kennedy) atop a Saturn IB rocket. The crew aboard were the astronauts selected for the first manned Apollo program mission: Command Pilot Virgil I. "Gus" Grissom, Senior Pilot Ed White and Pilot Roger B. Chaffee. All three died in the fire.
I was a little kid when that happened. We were a space family. My dad and most of his friends worked in and around the space biz which also accounts for the sixteen different schools I attended. We all watched the Apollo era from our front yards and in one case (Apollo 11) had the windows at my school broken due to the shockwave.
In an odd turn of events my office was at Complex 34 when Challenger blew up. That morning -- as many anniversaries before a mysterious donor sent out a wreath -- all black except three white roses -- one for each for Grissom, White and Chaffee. Like previous times, the wreath hung on the old blockhouse door and it served to remind us --people's lives were at stake. Later that day we lost the crew of Challenger.
Let's not to hijack Phil's thread and return to the discussion: there were some interesting things learned from both of these tragedies. One of the key contributors to the fire at CX34 was soldering. Wiring in the bird was messy to say the least. As I recall (and I'm no expert on this) the reason for the fire was a wire being pinched in the seat frame while the astronauts were in the capsule. What came from that were rigerous new standards on wiring -- particularly soldering. After the accident the weight of the vehicle fell by some 600 pounds -- all due to learning to solder things together and enforcing the rules through tight inspection. The quality of the product went up and we didn't kill any more people for awhile.
Another was the huge, wasteful nature of those times without limits or common sense. When I worked there we had a salvage facility on Ransom Road so called because a king's Ransom was buried there (or so I was told). Huge stockpiles of proportedly never used wire, cable, hardware of every sort -- even complete diesel powered generators -- were buried in the Florida sand. At least some of those tales were real because I actually did see large spools of cable rising through the ground along with a generator! Saw it first hand so I know at least some of it can be verified.
The explanation given was this is how they kept justifying the budget--ensuring all of it was used. Not unlike similar stories involving the military I've also heard. I wasn't there when it was going on -- only after the fact. So the lesson for me is that a lack of sensible management led to huge waste, fraud and abuse problems. Go figure 😉
There is a place for rules, standards, drawings, specs, inspection and the like. And there is also the place for raw, R&D talent unfettered by rules or specifications. Everyone would like to be in the cowboy group until something bad happens. Then the adults come home. Mom says you're gonna get a whuppin'!
October 2, 2009 at 6:14 am
Reply to rja.carnegie's comment: (I mistakenly assumed "replying" to an existing message would link it to that message.)
What stunned me was that it was stated exactly like that. (From what I have seen that is how it actually operates also.)
I was also stunned that someone would openly state it in an internal corporate web site.
It is as idiotic as the time a corporate controller (in a different company) told President that he did'nt get the Accounts Receiveable conversion done because "I didn't think Accounts Receivable was important." To which the President replied "Oh, Ok."
In both instances the people making the statement should have been canned. (In my NSHO)
October 2, 2009 at 6:41 am
Rowland Gosling (10/2/2009)
I was a little kid when that happened. We were a space family.
I assumed that was why you didn't jump on the "we got to the Moon no worries without a stupid dogmatic IT department". Because it was painfully close to home. Although it wasn't really a computer problem.
Didn't someone at Microsoft compare one release of Windows to putting men on the moon? Maybe the size of the budget? Or it could have been Apple's OS X, but that's got BSD underneath it, hasn't it?
Programming is harder these days partly because you have much more interface in any tool. There are probably more controls exposed and more that will go wrong if a careless user isn't protected from their own actions. In the imaginary good old days you'd just hand a user a punched card. And when they wanted to run their report, they would hand the card back to you.
Re software prototypes becoming the mission critical application unmodified and un-debugged, maybe the remedy is to include a conspiciuous and only semi-critical defect in the first draft version, and to insist that rigorous careful proper design and development will be needed to remove it. That doesn't have to be true, but it is probably true of the serious defect or limitation for real-world use that you haven't detected in your prototype by demonstration day. Getting permission to use more man-hourse! on the task means that that problem, the one that didn't show up in your proof-of-principle design and testing, will probably be removed.
October 2, 2009 at 7:57 am
rja.carnegie (10/2/2009)
Rowland Gosling (10/2/2009)
I was a little kid when that happened. We were a space family.I assumed that was why you didn't jump on the "we got to the Moon no worries without a stupid dogmatic IT department". Because it was painfully close to home. Although it wasn't really a computer problem.
That and I think I bring a unique perspective to the parallel of space exploration. Whenever NASA wants the public to think they're innovative, ingenious are just downright smart they whip out the image of how, through hard work and McGuiver-like Can-Do attitudes (complete with duct tape and chewing gum) we went to the moon. Really it was a painful, expensive exercise for the benefit of the military/industrial complex and largely useless bureaucrats.
There were smart people who could see beyond the launch control manuals that were over 8" thick and think for themselves -- to be sure. They were attended by some pretty dumb ones too. Good design can transcend ineptness.
To the other side of the coin, I recall some of the engine techs - the real geeks of that time. They could and did tune rocket engines by slight bends in the tubing that fed fuel. That was experience, art and science coming together through brilliance, luck, and ingenuity - the kind NASA likes to be known for. There isn't a spec for that 😉
October 5, 2009 at 3:12 pm
Phil is right on the mark.
I've often championed Agile Development in response to the big, fat practices common to corporate IT. My only complaint about Phil's editorial is that it shows how far the discussion of "Agile" has drifted from its original ideas. See http://agilemanifesto.org/ and click on "12 principles of Agile Software". That website is pretty old now and captures the essence of what Agile was supposed to be all about. It also happens to fit right in with Phil's editorial.
No "agile methodology" (Scrum, XP, etc.) captures the whole Agile manifesto, and because of this, some people want to dismiss Agile, claiming "it doesn't work." In addition, a great many people have thought they were implementing "agile methodologies" when in fact they were just using some buzzwords and a practice or two while missing the key ideas.
Instead we should make sure that our implementation of these methodologies stays true to the core of Agile, so we can maximize benefit from them, and then recognize that there is much remaining outside the scope of the methodologies. Phil is again right but doesn't go far enough: a lot of what remains is outside not just the current Agile methodologies, but outside the IT department. How can we create or evolve into an Agile organization (of which IT is a part)? A lot of the Agile signatories are working on this but it's probably the hardest part of the whole Agile proposition.
In such an organization there is no need to fear that a quickly-hacked up prototype will end up in production for years--maybe that is exactly what the company needs! And where that is what was needs, the developers who hacked it together and the people who decided to leave it that way should be praised! Other times this end result is harmful to the organization, and in order to be truly agile, the organization needs to be able to build the quick app, gain knowledge and experience from it, and keep evolving it until it maximizes its value.
I bring this up just to help prevent people from "throwing the baby out with the bathwater." Agile methodologies, well-implemented, have proven themselves valuable over and over--but not even their inventors claim that they are the magic bullet. I think that what we all want is an Agile organization.
Viewing 15 posts - 31 through 45 (of 48 total)
You must be logged in to reply to this topic. Login to reply