On Tue, Jun 22, 2010 at 01:23:14PM -0400, Adam M. Dutko wrote: > > This is obviously not the intent. The intent is to have software that > > is reasonably crafted by software engineers. Not some slapped together > > turd with peanuts from different development teams. > > > I agree it shouldn't be slapped together but you strike upon an interesting > debate... Should developers have to be software engineers and be certified? > Or are we OK with the "hacker" model? I hope you realize I'm not > insinuating "hacker" means crap coder! I tend to think it's a superior > model but it's also an evolutionary one, something most people don't "have > time for."
I don't really believe in tying people down to a certain methodology or process. I am a huge fan of doing things "the right way". This obviously means different things for different organizations. There really is no silver bullet for this. That said there are a couple of issues in any development organization that need to be dealt with. What it ultimately comes down to is how well respected quality control is. Quality control is not just verification; it is code style, best practices, unit test etc etc. If it is an afterthought and not taken seriously then your code will suck. You can add process, ISO certification and other BS all day which usually results in disaster because staff doesn't buy into it. And I'll tell you the true success to software development. Good engineers that know their stuff and are willing to work within a framework. This means hiring people and paying them what they are worth. Getting a bunch of kids from college with some degree or another or outsourcing code is a recipe for disaster. If the developers have no vested interest in the success of the code a project will nearly always fail. I have seen some colossal failures over time and they usually start when people become resources. Anyway I can ramble about this for days. > > > > Not interesting and not even true. Anyone who coded in the old world > > with lets say threads, knew that going to a newer better faster machine > > would always result in nice new racing bugs. I won't get into why this > > happened though. > > > > Sure, doing things faster doesn't mean it'll be better. Often it just means > you'll hit a lock problem quicker than if you went slower. Can you > elaborate on what you mean though...what's the equivalent to code rust? API > breakage? Windows seems to have maintained crazy backwards compatibility. > Not that I'm applauding it because it also means malicious can still run > unless other means are leveraged to block it. You misunderstood me. I meant in the old days running old code on new machines nearly always meant breakage because it was poorly written at most levels (OS, API, Apps etc) > > > > Reasonable quality control is something people shouldn't hope for it > > should be something people demand. The reason why we have windows the > > way it is today is that in the early days people didn't put their foot > > down and said "ENOUGH". The rest is history. > > > > I agree that's part of the reason. > > > > The reason why Apple is making such big strides with OSX is because they > > are capitalizing on this general feeling. OSX unlike windows isn't > > naturally chaotic and Apple does a fine job pretending they are secure. > > All in all a pretty smart marketing campaign that seems to be paying the > > bills just fine. > > > Yes, until the other shoe drops. > > > > Your car runs hundreds of thousands (if not millions) of lines of code. > > Does it crash all the time? Microsoft spends more money on R&D than > > NASA has to develop a rocket. Are you sure that they should not have > > been capable of any standard of quality? > > > Not all the time, but there are many documented cases, not the least of > which being the current "popular hybrid car maker" debacle. > > I've looked up a couple of reports on money spent specifically to improve > quality for Microsoft and for NASA. NASA gives us a number at > http://www.nasa.gov/pdf/420990main_FY_201_%20Budget_Overview_1_Feb_2010.pdfbut > the number I found was specific to a group within NASA not as a whole. > If you also count the Air Force space program which is much bigger but is > also "involved" with NASA, the number becomes much larger: > http://www.saffm.hq.af.mil/shared/media/document/AFD-100201-050.pdf. Most > of the information I found in Microsoft's filing and various news media > articles doesn't talk about specific research for "quality improvements." > They talk about "vague" concepts. > > I do believe they're all capable of better quality software, it's just hard > and expensive. Each are avoided like the plague in most corporate > environments. Microsoft spends $10B on R&D. That is nearly the ENTIRE budget of NASA. They are the classic example of organizations that are completely out of control and rely entirely on some process that is "good enough". Anyone who has written code that directly interacts with their APIs knows how completely disjoint their development teams are. They don't even adhere to the same damn style for functions calls. If you really want to have some fun with that number go figure out where they make their money. Then figure out how much each line of code cost. Pretty baffling stuff.
