That's what people sayd about O/O in the eighties.
on
Microsoft Lauds Scrum
·
· Score: 2, Insightful
They're not the latest big thing - they are the software manifestation of the same practices/principles used to create the Toyota Production System - practices that then have been adopted across the whole car industry. Nay-say all you want, but if you haven't tried it, then you have nothing productive to say for or against. Talk talk talk.
... Scrum/Agile isn't about "combatting OSS", it's about doing what any software dev shop, OR open source software project needs to do - improve team productivity, roll out features in a structured, efficient, and systematic way. More importantly, it's about not pretending that a large two-year effort can be completely understood in a three month requirements gathering phase. It's about admitting that the low-level tasks that some project manager assigns to a junior programmer 14 months before won't be valid when the rubber hits the road. It's about maximizing the capabilities of softawre teams, improving collaboration and effectiveness, clarifying priorities, eliminating waste.
I'm no huge fan of microsoft, and all my servers run OpenBSD, but jeez, this is fanatical trolling. For the record, some open-source projects use agile methods.
BSD's are not kernels, they are operating systems. OpenSBD 3.8 is not the OpenBSD 3.8 kernel, it is the kernel, the base system, the utilities, the compiler, the hardware support, the new server software, etc. Therefore when OpenBSD (or the other BSDs) say "new, 3.14159 is released, you should actually care if you run that system. It means new features, new hardware support, and sometimes new whole pieces of software... just like when windows or mac release a new version.
I really hate it when linux watchers forget that their world is not like other worlds... .
Foo result = null; if (target.canPerformMethod("processFoo:String:Foo")) {
result = (Foo)target.performMethod("processFoo:String:Foo", "Pro ccessing Foo",aFoo); }
The earlier one would have invoked a non-existant method. Should have written the Unit Test first...:)
I also should mention that the above is used to hit arbitrary methods, so you don't have to know the specific class/interface up-front. This is really really useful in plug-in interfaces for applications, for example. And yes, you can re-structure your code around strong interfaces and all sorts of things to avoid having to do this, but sometimes this kind of approach saves 10s and 100s of lines of code, and as long as you perform the check, it's safe as houses.
If you have such problems in Java then write a really small little class that does all this work for you, generically, in one place, so you can access it by saying
Many java frameworks are terrible, but that's a matter of API aesthetic. For instance, I hate the Java frameworks' APIs for reflection and dynamic method invocation and such. So I wrap it all in two methods
public boolean canPerformMethod(String methodSignature);
public Object performMethod(String methodSignature,Object param1... Object paramN);
(Note: the above is pseudo-code so I don't have to explain how to do variable number of parameters in Java 5 - not all/.ers are Java coders.) (Note2: By using aspect-oriented programming, I can insert these methods high-up in the object-hierarchy)
The point is that now, anywhere in my code I can dynamically invoke methods by:
Foo result = null; if (target.canPerformMethod("processFoo:String:Foo")) {
result = (Foo)target.performMethod("method:String:Foo","Pro ccessing Foo",aFoo); }
That simple structure replaces about 10-20 lines of exception handling, method lookup, and all sorts of crap, because I (wait for it) encapsulated it.
I'm not saying it's not convenient to have mail(...). Of course it is. But the point of languages like Java is that if you have a preferred API, you can wrap the complexity of a crappy API with a nicer convenient one in your own code. That's called good programming. No actualy need to whine.
It's only when the raw functionality is not there, or when the raw langauge/runtime capabilities don't actually allow you to create the functionality you want in a convenient form - that's when whining is necessary. But modern Java, with Java 5 + aspectJ pretty much allows anything to be created in relatively convenient APIs.
The only remaining issue is to convince someone at Sun to refactor their core APIs into something that provides some of this convenience out-of-the-box. Or go write Objective-C against the Cocoa APIs on MacOSX. They're pretty nice.
... can you pack into one single rant?!? If only any of this tripe weren't founded on a philosophy whose latest adherents' exploits include "debunking" heizenberg's uncertainty principle and Godel's theorem. Anti-scientific AND anti-religious; ravingly individualist yet totally happy with the collectivist system of corporatism. Anti-statist, yet they are happy to have the state use their power in favour of corporate property over individual property. It's quite the "have-cake, eat-too" package.
... several large financial firms I can't mention, the department of defense, most of modern manufacturing, 3M, etc.
More versions isn't what Agile/Lean means. It means more iterations. You make versions (or releases) when you're ready to go to market. That's a business decision. You will certainly have many iterations before your business feels you've built enough to go to market. The technical job is to make sure that, to the extent you've gotten to high-priority scope, the quality of the code is such that it could be released at the end of any iteration, if the business sees enough of it's features in.
People like Martin, Schwaber, Popendiek, Augustine, and the like... they have helped companies release 500K+ lines of code projects. Now explain WHY you feel large projects cannot use Lean or Agile. And what in God's name made you think that there was no change control or worries about upgrades or localization.
Perhaps Mr. Highsmith was engaging at too philosophical a level, and expecting you folks to adapt Lean/Agile to your environment. If you have heavy release control needs, you sync up the cycles to your release cycles.
Jeez, what is wrong with people on slashdot. Criticize with substance, not merely ad-hominem. Some of us "Agile guys" have done what you say we don't know how to do.
Lean Six Sigma is an application of Lean practice and principles to Six Sigma quality control.
They both come from the same background, which is nicely summed up in The Machine That Changed The World, by James Womack. Lean, Total Quality Management, Six Sigma, and Agile all owe substantial debts to Toyota, and this book describes it nicely.
Lean manufacturing was around in the 70's, based on the Toyota Production System. Agile is an application of lean princples to Software Development. Or more accurately, if you apply lean principles and tools to software development, you get Agile practices, since Agile practices are the natural result of Lean thinking.
More importantly, Mary has delivered real product from more projects than most of us have ever attempted. She brings real credentials earned in product development to the table. What do you bring besides attitude?
Honestly, look it up, before you pull more drivel out and bandy it about as if you were clever.
It's got replication, highly configurable workflow management, and is integrated fully with Synergy/Change and DOORS. It also has a nifty feature called ActiveCM, which is an explorer SCM integration that rocks for uninitiated users. Like Tortoise{CVS|SVN} only smarter. Just a thought. I recently reviewed them for a Change/SCM software purchase by my client. They went (against my recommendation) with IBM.
(No, I don't work for them, nor have accepted any compensation from them. -i)
Untrue. I'm all for change control, both at the source and requirements level. Good Agile development does not do away with documenting requirements - in fact it must, but you don't spend time documenting every possible requirement. You document what you must, and you track changes to everything, source, docs, specs, etc.
I'm not advocating a fundamentalist position here. In fact, fanatic agile people are, by definition, not agile. You need to have balance and judgement. If you don't document anything out of a "principle", they you're just as foolish as those who document everything for two years before the project starts.
The point of not over-dcoumenting requirements, is that THEY WILL CHANGE and be obsolete by the time you're done capturing them all. So you capture what you need for a small set of iterations, document them, implement them, then document the next delta, implement the next delta, etc.
A very well respected (if a bit obscure) OO language is Objective-C. It has a few features that are analogous to aspects.
First it has categories, which allow you to add new methods, or replace the implementation of a method in a given class. You add a category to that class that includes, say, a replacement description method, and the new implementation replaces the old. Or you can add a path utility methods to the String class, as another example.
It also has "poseAs", which allows you to insert an object into a hierarchy. Say you have Class B which extends Class A. But you want custom behaviour to be accessible to all As children (including, for example, B). You create Class C, which extends A, and make it poseAs Class A. Now the runtime hooks all clesses that inherit A off of C, which replaces A. A still exists, but is in the background, providing normal inherited functionality to C.
These abilities were one of the things that made Objective C a very powerful OO language. In particular, it allows a particular kind of reuse, by virtue of allowing one to patch someone else's library without having source. So if you want to add the aforementioned path utilities to NSString, you just added a Category in your own code, and your code would run with the extended functionality in NSString (no one elses would, unless they used your category too). This means that often you can make the most out of someone else's code without a complete rewrite.
It isn't all powerful. There are access and visibility restrictions. It is also used to partition code for ease of organization and better modularization. Here's the point:
Because it is a well known feature of the language, you think in terms of categories, and you know to look for categories. This can be aided by tools, but you most definitely need to pay attention to them. But because of this, they are only "dangerous" if you aren't paying attention. And guess what! That's true of programming, period.
Oh my sweet lord, when will the madness end.
on
Microsoft's 911 Patent
·
· Score: 4, Insightful
I'm sorry, but isn't the actual 911 (not 9/11) emergency services network considered prior art? And what about this makes it patentable, other than the complete insanity of the US Patent Office. This seems almost as rediculous as "One Click Shopping". Or hey, forget about originality, what about non-obviousness?
The five steps enumerated here are, sadly, rather untenable. In particular, points one and two make a fundamental assumption that I believe is invalid - get your requirements first. If we have learned nothing in the past 40 years of software, and especially in the last decade, it's that we will never have "the requirements." We will have subsets, or views of the requirements, true. The fact, however, is that requirements change during the life of the product development.
Skipping to point four for a moment: I would argue that the requirements should be expressed in the form of tests - functional, unit, or otherwise, and that these tests be executable. The design MUST therefore meet the requirements. This then means that point number three may or may not apply.
I agree that code is not design. Design is abstract, and code is not. And pure-code-no-design folks go overboard in my view, but if you can't have complete requirements (and you can't) then you certainly should document that which is not obvious from a structural breakdown of the code itself. Particularly, documenting risky or unusual features of the code, such as tortured relationships and their semanitcs. To me that is the limit. Document what is not obvious, do not document what is structurally implicit, or otherwise explicit. Documentation covers risk, and risk mitigation points (ie. person hours) are best spent making better software, except when documenting something that, if left unsaid, might lead other developers to an incorrect assumption or conclusion.
As to point number five, your experience may vary. In my experience, it's quite the reverse. But in the example I'm thinking about, we didn't have each individual designing - the whole team designed together, and the whole team coded and tested, and never alone. Also, design changes, or any changes to assumptions (or APIs, or etc.) were well published throughout the team, so that there was ongoing restatement of context. If anyone thought that something was an odd or interesting design feature/artifact, they mentioned it, and the author clarified it and documented it. I don't think having individuals altering design outside of a process of consultation is wise, and I think this "cowboy" flavour of agile developent is abortive and a throwback to no-process development. However, small teams that are engaged collectively produce, in my experience, excellent design. You then need to capture what is not obvious, or somewhat obfuscated, and especially capture assumptions.
Where ThosLives and I would agree, however, I think, is that you need to trace design aspects to requirements. You may not have final requirements, but you always have some, and you shoulnt' make design decisions without a requirement to trace to. In this sense, you absolutely must have tracability from requirement to design to implementation to proof (test). And if requirement can be expressed as a test (not all requirements can), then that is, in my view, the best way.
... since such principles can be applied more generally than standards. Admittedly, they can't be as easily verified, but they can help to create a culture of quality.
Back in the NeXTSTEP days, the API documentation was fanatically good, and several companies that transitioned from NeXTSTEP to Java applied this level of API documentation quality to JavaDoc comments, complete with overviews, TOC's, footnotes, usage-guides, etc. linked together with the JavaDoc shell. This was a kind of quality that was based on a culture, which held up a principle of documenting useful APIs well and usefully. It was spontaneous, and not part of any formal standard, but it really helped. (Not all companies, mind you...:)
What could some of these principles be? Things like:
- Adequately document public APIs
- Commit to removing irrelevant and obsolete code
- Commit to finding and fixing certain kinds of errors before adding new features (buffer overflows, malloc errors, retain cycles, etc.)
- Commit to making software usable by non-geeks, if the software target audience is non-geek.
- .
Ok, I understand very much the theory you are proposing, but you're actually supposing it. You don't have evidence. It sounds good, but we have started, with the article, to examine evidence of lying/truthtelling and its effect on brain activity. I don't think we can just toss around this kind of "common-sense" theory as if it were true, when we actually have the means now to test it.
Also, have we looked at the methodology of the study? Did it include efforts to fool the fMRI? I've seen a lot of smug answers and comments like the parent here, but seriously, they're not working from data, they're working from presuppositions on how the brain works, or even how lying works.
Why is the possibility that the mind know truth from falsehood so hard to accept? Maybe you're right, maybe it can be fooled, but let's at least be open to the possibilities and get impirical data to prove or disprove it.
... which is a magazine, and not to be confused with the profession. In fact, I know of a few newspapers with that sort of name: The Economist and Sun, the Economist-Tribune.
Newspaper and magazine names are usually historical, and the words they contain have often changed meaning. For example, there is a local newspaper north of Toronto called "The Liberal". This newspaper has, for example, no ties to the Liberal Party, is not particularly philosophically Liberal (whatever that means), and is basically a local community newspaper that was named almost a century ago {more or less). What's in a name? Often, when it comes to media titles and tag-lines... nothing.
Just rememeber, "fair and balanced" is the tagline of Fox News.
1. Scrum, as an example of an "Agile project shell" can be quite adept at large projects. Largest one I've heard of had about twenty teams. At my recent Scrum training, one organization were finding creative ways of implementing agile processes across two continents and three major centres. You still get value from "Agile" at a distance, but it's less valuable. However, large, monolithic defined processes, such as RUP, waterfall, etc., don't work, imperically. They come in late, with less functionality than planned for, and over budget. Can they work? Yes. Where there is increasing complexity, agile approaches are better.
2. Name me a method that works when your developers are thousands of miles away, in different time zones, with a totally different culture, and who don't speak your native language. What's that? They all suffer? In that case, why don't you go for the ones that manage complexity the best. Impirical processes (short cycles, lots of measurement, feedback cycles) work better than defined processes (requiremenents fully articulated and not changing, can be completed before the requirements are out of date, all your developers are of the same (expected) quality, all your communications are relatively noiseless, misunderstandings from documentation are within small error tolerances, etc.)
Guess what. You might complain about agile not working at a distance, but by normal success metrics, (time, cost, quality, function) traditional methods don't work either.
Having delivered software with both kinds of processes, I can tell you, you get far more control and corrective ability with an agile process like Scrum than with RUP on a two-year project... and you deliver business value faster.
3. You can mix and match. Agile approaches are approaches. You can, though you incur a cost, take some agile practices and use them in a non-agile context. You can take RUP practices and use them in an Agile context. You don't get all the benefits of either, but in your specific context, you can get the benefits you choose. Each project is different, and no method properly addresses every project's particularities. But the more adaptable the process, the better. This can be either the way RUP does, by having so many steps and layers that you can choose what you need, and "lighten" it by scraping out the rest. The other approach is to have a lightweight agile management framework that is powerful because of it's feedback systems, and doesn't make presumptions about steps in the same way as a larger process. The power from the latter comes because you get constant feedback of progress in a way that is impossible to relate to business value in a more monolithic process. Because you can relate it to business value, you can constantly be tweaking the project to match the business interests.
Pick your poison, but don't toss out the baby with the propaganda.
... rather it is the responsibility of someone creating a new product to demonstrate its safety. That's the point. If it's new, and its effects unknown, then you don't dress up little billy or sally in it.
Are there links that show studies and theories as to why/how this would be safe as a material? No one thought asbestos was nasty until much later. How will we avoid the same mistake this time?
The fact that a Canadian firm has a US parent doesn't excuse that company from giving away data entrusted to it by any Canadian government to any other firm or government not authorized to receive it by the same Canadian government.
... if you go on Apple's site looking for Darwin binaries, they send you to OpenDarwin. It's like saying "Slackware is a project to complete what Linux couldn't or wouldn't". It's technically true, but not relevant. Darwin is the Core, OpenDarwin is the whole environment. Apple releases their own, and it's called MacOSX.
And yes, it uses a Mach microkernel (which was derived from BSD) and has a BSD kernel personality. That is to say, from an external API level, it looks like a daemon and quacks like a daemon... It's userland is all FreeBSD, NetBSD and OpenBSD userland tools. How much more BSD do you need. So it has a different, related kernel. So do the big three BSDs. It has more in common with these than most other OSs.
As for Theo, he has my abiding respect, even after an argument we had. He had some good points. I think I did too. The fact is that he doesn't suffer fools, and he is quick to resolve the evidence in front of him. He may have false positives. Frankly, though, you have to be a particular weenie to actually be flamed off the internet. That's hard-core victim mentality right there. "Ooooh, theo said a bad thing to me.... mommeeeeeeeeeee." No one likes to be disliked by anyone, especially whom they respect, but that's life. Deal with it.
MacOS (and it's predecessor, NeXTSTEP) supports a notion called "Fat Binaries", where a binary has a shared text segment, and a separate code segment for each supported architecture. For a while, you had software distributed for m68k, i386, sparc, and hppa-risc all in one binary package.
And the developer tools supported this natively. All you did was choose the arch you cared to compile for, or archs, and it would magically spew out the binary, which you could run on any system.
MacOSX may not actually demonstrate this capability, but Rhapsody (MacOSX -1) had it, and the capability wasn't stripped out. Vendors would simply re-compile, unless they used assembler.
Slashdot Mirror
They're not the latest big thing - they are the software manifestation of the same practices/principles used to create the Toyota Production System - practices that then have been adopted across the whole car industry. Nay-say all you want, but if you haven't tried it, then you have nothing productive to say for or against. Talk talk talk.
... Scrum/Agile isn't about "combatting OSS", it's about doing what any software dev shop, OR open source software project needs to do - improve team productivity, roll out features in a structured, efficient, and systematic way. More importantly, it's about not pretending that a large two-year effort can be completely understood in a three month requirements gathering phase. It's about admitting that the low-level tasks that some project manager assigns to a junior programmer 14 months before won't be valid when the rubber hits the road. It's about maximizing the capabilities of softawre teams, improving collaboration and effectiveness, clarifying priorities, eliminating waste.
I'm no huge fan of microsoft, and all my servers run OpenBSD, but jeez, this is fanatical trolling. For the record, some open-source projects use agile methods.
BSD's are not kernels, they are operating systems. OpenSBD 3.8 is not the OpenBSD 3.8 kernel, it is the kernel, the base system, the utilities, the compiler, the hardware support, the new server software, etc. Therefore when OpenBSD (or the other BSDs) say "new, 3.14159 is released, you should actually care if you run that system. It means new features, new hardware support, and sometimes new whole pieces of software... just like when windows or mac release a new version.
I really hate it when linux watchers forget that their world is not like other worlds...
.
For the pendantic, this is what I meant:
) {, "Pro ccessing Foo",aFoo);
:)
Foo result = null;
if (target.canPerformMethod("processFoo:String:Foo")
result = (Foo)target.performMethod("processFoo:String:Foo"
}
The earlier one would have invoked a non-existant method. Should have written the Unit Test first...
I also should mention that the above is used to hit arbitrary methods, so you don't have to know the specific class/interface up-front. This is really really useful in plug-in interfaces for applications, for example. And yes, you can re-structure your code around strong interfaces and all sorts of things to avoid having to do this, but sometimes this kind of approach saves 10s and 100s of lines of code, and as long as you perform the check, it's safe as houses.
.
If you have such problems in Java then write a really small little class that does all this work for you, generically, in one place, so you can access it by saying
... headerN);
... Object paramN);
/.ers are Java coders.)
) {o ccessing Foo",aFoo);
Mailer.mail(to,from,subject,message,header1
Many java frameworks are terrible, but that's a matter of API aesthetic. For instance, I hate the Java frameworks' APIs for reflection and dynamic method invocation and such. So I wrap it all in two methods
public boolean canPerformMethod(String methodSignature);
public Object performMethod(String methodSignature,Object param1
(Note: the above is pseudo-code so I don't have to explain how to do variable number of parameters in Java 5 - not all
(Note2: By using aspect-oriented programming, I can insert these methods high-up in the object-hierarchy)
The point is that now, anywhere in my code I can dynamically invoke methods by:
Foo result = null;
if (target.canPerformMethod("processFoo:String:Foo")
result = (Foo)target.performMethod("method:String:Foo","Pr
}
That simple structure replaces about 10-20 lines of exception handling, method lookup, and all sorts of crap, because I (wait for it) encapsulated it.
I'm not saying it's not convenient to have mail(...). Of course it is. But the point of languages like Java is that if you have a preferred API, you can wrap the complexity of a crappy API with a nicer convenient one in your own code. That's called good programming. No actualy need to whine.
It's only when the raw functionality is not there, or when the raw langauge/runtime capabilities don't actually allow you to create the functionality you want in a convenient form - that's when whining is necessary. But modern Java, with Java 5 + aspectJ pretty much allows anything to be created in relatively convenient APIs.
The only remaining issue is to convince someone at Sun to refactor their core APIs into something that provides some of this convenience out-of-the-box. Or go write Objective-C against the Cocoa APIs on MacOSX. They're pretty nice.
... can you pack into one single rant?!? If only any of this tripe weren't founded on a philosophy whose latest adherents' exploits include "debunking" heizenberg's uncertainty principle and Godel's theorem. Anti-scientific AND anti-religious; ravingly individualist yet totally happy with the collectivist system of corporatism. Anti-statist, yet they are happy to have the state use their power in favour of corporate property over individual property. It's quite the "have-cake, eat-too" package.
.
... several large financial firms I can't mention, the department of defense, most of modern manufacturing, 3M, etc.
More versions isn't what Agile/Lean means. It means more iterations. You make versions (or releases) when you're ready to go to market. That's a business decision. You will certainly have many iterations before your business feels you've built enough to go to market. The technical job is to make sure that, to the extent you've gotten to high-priority scope, the quality of the code is such that it could be released at the end of any iteration, if the business sees enough of it's features in.
People like Martin, Schwaber, Popendiek, Augustine, and the like... they have helped companies release 500K+ lines of code projects. Now explain WHY you feel large projects cannot use Lean or Agile. And what in God's name made you think that there was no change control or worries about upgrades or localization.
Perhaps Mr. Highsmith was engaging at too philosophical a level, and expecting you folks to adapt Lean/Agile to your environment. If you have heavy release control needs, you sync up the cycles to your release cycles.
Jeez, what is wrong with people on slashdot. Criticize with substance, not merely ad-hominem. Some of us "Agile guys" have done what you say we don't know how to do.
Lean Six Sigma is an application of Lean practice and principles to Six Sigma quality control.
They both come from the same background, which is nicely summed up in The Machine That Changed The World, by James Womack. Lean, Total Quality Management, Six Sigma, and Agile all owe substantial debts to Toyota, and this book describes it nicely.
Lean manufacturing was around in the 70's, based on the Toyota Production System. Agile is an application of lean princples to Software Development. Or more accurately, if you apply lean principles and tools to software development, you get Agile practices, since Agile practices are the natural result of Lean thinking.
More importantly, Mary has delivered real product from more projects than most of us have ever attempted. She brings real credentials earned in product development to the table. What do you bring besides attitude?
Honestly, look it up, before you pull more drivel out and bandy it about as if you were clever.
... is available on the iTunes store podcast section. Search for "Agile". Otherwise, you can get it here.
... welcome our new plastic-encased overlords.
It's got replication, highly configurable workflow management, and is integrated fully with Synergy/Change and DOORS. It also has a nifty feature called ActiveCM, which is an explorer SCM integration that rocks for uninitiated users. Like Tortoise{CVS|SVN} only smarter. Just a thought. I recently reviewed them for a Change/SCM software purchase by my client. They went (against my recommendation) with IBM.
(No, I don't work for them, nor have accepted any compensation from them. -i)
Untrue. I'm all for change control, both at the source and requirements level. Good Agile development does not do away with documenting requirements - in fact it must, but you don't spend time documenting every possible requirement. You document what you must, and you track changes to everything, source, docs, specs, etc.
I'm not advocating a fundamentalist position here. In fact, fanatic agile people are, by definition, not agile. You need to have balance and judgement. If you don't document anything out of a "principle", they you're just as foolish as those who document everything for two years before the project starts.
The point of not over-dcoumenting requirements, is that THEY WILL CHANGE and be obsolete by the time you're done capturing them all. So you capture what you need for a small set of iterations, document them, implement them, then document the next delta, implement the next delta, etc.
Woops, forgot to add a C2 Wiki entry for Objective-C.
A very well respected (if a bit obscure) OO language is Objective-C. It has a few features that are analogous to aspects.
First it has categories, which allow you to add new methods, or replace the implementation of a method in a given class. You add a category to that class that includes, say, a replacement description method, and the new implementation replaces the old. Or you can add a path utility methods to the String class, as another example.
It also has "poseAs", which allows you to insert an object into a hierarchy. Say you have Class B which extends Class A. But you want custom behaviour to be accessible to all As children (including, for example, B). You create Class C, which extends A, and make it poseAs Class A. Now the runtime hooks all clesses that inherit A off of C, which replaces A. A still exists, but is in the background, providing normal inherited functionality to C.
These abilities were one of the things that made Objective C a very powerful OO language. In particular, it allows a particular kind of reuse, by virtue of allowing one to patch someone else's library without having source. So if you want to add the aforementioned path utilities to NSString, you just added a Category in your own code, and your code would run with the extended functionality in NSString (no one elses would, unless they used your category too). This means that often you can make the most out of someone else's code without a complete rewrite.
It isn't all powerful. There are access and visibility restrictions. It is also used to partition code for ease of organization and better modularization. Here's the point:
Because it is a well known feature of the language, you think in terms of categories, and you know to look for categories. This can be aided by tools, but you most definitely need to pay attention to them. But because of this, they are only "dangerous" if you aren't paying attention. And guess what! That's true of programming, period.
I'm sorry, but isn't the actual 911 (not 9/11) emergency services network considered prior art? And what about this makes it patentable, other than the complete insanity of the US Patent Office. This seems almost as rediculous as "One Click Shopping". Or hey, forget about originality, what about non-obviousness?
Jeesh.
The five steps enumerated here are, sadly, rather untenable. In particular, points one and two make a fundamental assumption that I believe is invalid - get your requirements first. If we have learned nothing in the past 40 years of software, and especially in the last decade, it's that we will never have "the requirements." We will have subsets, or views of the requirements, true. The fact, however, is that requirements change during the life of the product development.
Skipping to point four for a moment: I would argue that the requirements should be expressed in the form of tests - functional, unit, or otherwise, and that these tests be executable. The design MUST therefore meet the requirements. This then means that point number three may or may not apply.
I agree that code is not design. Design is abstract, and code is not. And pure-code-no-design folks go overboard in my view, but if you can't have complete requirements (and you can't) then you certainly should document that which is not obvious from a structural breakdown of the code itself. Particularly, documenting risky or unusual features of the code, such as tortured relationships and their semanitcs. To me that is the limit. Document what is not obvious, do not document what is structurally implicit, or otherwise explicit. Documentation covers risk, and risk mitigation points (ie. person hours) are best spent making better software, except when documenting something that, if left unsaid, might lead other developers to an incorrect assumption or conclusion.
As to point number five, your experience may vary. In my experience, it's quite the reverse. But in the example I'm thinking about, we didn't have each individual designing - the whole team designed together, and the whole team coded and tested, and never alone. Also, design changes, or any changes to assumptions (or APIs, or etc.) were well published throughout the team, so that there was ongoing restatement of context. If anyone thought that something was an odd or interesting design feature/artifact, they mentioned it, and the author clarified it and documented it. I don't think having individuals altering design outside of a process of consultation is wise, and I think this "cowboy" flavour of agile developent is abortive and a throwback to no-process development. However, small teams that are engaged collectively produce, in my experience, excellent design. You then need to capture what is not obvious, or somewhat obfuscated, and especially capture assumptions.
Where ThosLives and I would agree, however, I think, is that you need to trace design aspects to requirements. You may not have final requirements, but you always have some, and you shoulnt' make design decisions without a requirement to trace to. In this sense, you absolutely must have tracability from requirement to design to implementation to proof (test). And if requirement can be expressed as a test (not all requirements can), then that is, in my view, the best way.
... since such principles can be applied more generally than standards. Admittedly, they can't be as easily verified, but they can help to create a culture of quality.
:)
Back in the NeXTSTEP days, the API documentation was fanatically good, and several companies that transitioned from NeXTSTEP to Java applied this level of API documentation quality to JavaDoc comments, complete with overviews, TOC's, footnotes, usage-guides, etc. linked together with the JavaDoc shell. This was a kind of quality that was based on a culture, which held up a principle of documenting useful APIs well and usefully. It was spontaneous, and not part of any formal standard, but it really helped. (Not all companies, mind you...
What could some of these principles be? Things like:
- Adequately document public APIs
- Commit to removing irrelevant and obsolete code
- Commit to finding and fixing certain kinds of errors before adding new features (buffer overflows, malloc errors, retain cycles, etc.)
- Commit to making software usable by non-geeks, if the software target audience is non-geek.
- .
Ok, I understand very much the theory you are proposing, but you're actually supposing it. You don't have evidence. It sounds good, but we have started, with the article, to examine evidence of lying/truthtelling and its effect on brain activity. I don't think we can just toss around this kind of "common-sense" theory as if it were true, when we actually have the means now to test it.
Also, have we looked at the methodology of the study? Did it include efforts to fool the fMRI? I've seen a lot of smug answers and comments like the parent here, but seriously, they're not working from data, they're working from presuppositions on how the brain works, or even how lying works.
Why is the possibility that the mind know truth from falsehood so hard to accept? Maybe you're right, maybe it can be fooled, but let's at least be open to the possibilities and get impirical data to prove or disprove it.
... which is a magazine, and not to be confused with the profession. In fact, I know of a few newspapers with that sort of name: The Economist and Sun, the Economist-Tribune.
Newspaper and magazine names are usually historical, and the words they contain have often changed meaning. For example, there is a local newspaper north of Toronto called "The Liberal". This newspaper has, for example, no ties to the Liberal Party, is not particularly philosophically Liberal (whatever that means), and is basically a local community newspaper that was named almost a century ago {more or less). What's in a name? Often, when it comes to media titles and tag-lines... nothing.
Just rememeber, "fair and balanced" is the tagline of Fox News.
1. Scrum, as an example of an "Agile project shell" can be quite adept at large projects. Largest one I've heard of had about twenty teams. At my recent Scrum training, one organization were finding creative ways of implementing agile processes across two continents and three major centres. You still get value from "Agile" at a distance, but it's less valuable. However, large, monolithic defined processes, such as RUP, waterfall, etc., don't work, imperically. They come in late, with less functionality than planned for, and over budget. Can they work? Yes. Where there is increasing complexity, agile approaches are better.
2. Name me a method that works when your developers are thousands of miles away, in different time zones, with a totally different culture, and who don't speak your native language. What's that? They all suffer? In that case, why don't you go for the ones that manage complexity the best. Impirical processes (short cycles, lots of measurement, feedback cycles) work better than defined processes (requiremenents fully articulated and not changing, can be completed before the requirements are out of date, all your developers are of the same (expected) quality, all your communications are relatively noiseless, misunderstandings from documentation are within small error tolerances, etc.)
Guess what. You might complain about agile not working at a distance, but by normal success metrics, (time, cost, quality, function) traditional methods don't work either.
Having delivered software with both kinds of processes, I can tell you, you get far more control and corrective ability with an agile process like Scrum than with RUP on a two-year project... and you deliver business value faster.
3. You can mix and match. Agile approaches are approaches. You can, though you incur a cost, take some agile practices and use them in a non-agile context. You can take RUP practices and use them in an Agile context. You don't get all the benefits of either, but in your specific context, you can get the benefits you choose. Each project is different, and no method properly addresses every project's particularities. But the more adaptable the process, the better. This can be either the way RUP does, by having so many steps and layers that you can choose what you need, and "lighten" it by scraping out the rest. The other approach is to have a lightweight agile management framework that is powerful because of it's feedback systems, and doesn't make presumptions about steps in the same way as a larger process. The power from the latter comes because you get constant feedback of progress in a way that is impossible to relate to business value in a more monolithic process. Because you can relate it to business value, you can constantly be tweaking the project to match the business interests.
Pick your poison, but don't toss out the baby with the propaganda.
... rather it is the responsibility of someone creating a new product to demonstrate its safety. That's the point. If it's new, and its effects unknown, then you don't dress up little billy or sally in it.
Are there links that show studies and theories as to why/how this would be safe as a material? No one thought asbestos was nasty until much later. How will we avoid the same mistake this time?
The fact that a Canadian firm has a US parent doesn't excuse that company from giving away data entrusted to it by any Canadian government to any other firm or government not authorized to receive it by the same Canadian government.
That's called espionage and treason, baby...
Cheers.
... if you go on Apple's site looking for Darwin binaries, they send you to OpenDarwin. It's like saying "Slackware is a project to complete what Linux couldn't or wouldn't". It's technically true, but not relevant. Darwin is the Core, OpenDarwin is the whole environment. Apple releases their own, and it's called MacOSX.
And yes, it uses a Mach microkernel (which was derived from BSD) and has a BSD kernel personality. That is to say, from an external API level, it looks like a daemon and quacks like a daemon... It's userland is all FreeBSD, NetBSD and OpenBSD userland tools. How much more BSD do you need. So it has a different, related kernel. So do the big three BSDs. It has more in common with these than most other OSs.
As for Theo, he has my abiding respect, even after an argument we had. He had some good points. I think I did too. The fact is that he doesn't suffer fools, and he is quick to resolve the evidence in front of him. He may have false positives. Frankly, though, you have to be a particular weenie to actually be flamed off the internet. That's hard-core victim mentality right there. "Ooooh, theo said a bad thing to me.... mommeeeeeeeeeee." No one likes to be disliked by anyone, especially whom they respect, but that's life. Deal with it.
MacOS (and it's predecessor, NeXTSTEP) supports a notion called "Fat Binaries", where a binary has a shared text segment, and a separate code segment for each supported architecture. For a while, you had software distributed for m68k, i386, sparc, and hppa-risc all in one binary package.
And the developer tools supported this natively. All you did was choose the arch you cared to compile for, or archs, and it would magically spew out the binary, which you could run on any system.
MacOSX may not actually demonstrate this capability, but Rhapsody (MacOSX -1) had it, and the capability wasn't stripped out. Vendors would simply re-compile, unless they used assembler.
i.