However, the original Agile Manifesto was powerful because it made tradeoffs. "We value X over Y", even when Y is a valuable thing. For this HDD thing to take off, it has to make the similar tradeoffs explicit.
For example:
We value readable code over runtime performance.
We value open-source frameworks and libraries over developing for popular ecosystems.
We value inclusiveness, diversity, and respect over pure meritocracy.
We value teaching, learning, and improving our craft over short-term productivity.
We value creating wealth over capturing wealth."We value open-source frameworks and libraries over developing for popular ecosystems."
Most popular ecosystems nowadays are all open-source frameworks and libraries? Unless you're talking about Windows or Mac OSX, I guess?
"We value inclusiveness, diversity, and respect over pure meritocracy."
These are not mutually exclusive goals--even if they are, I'd rather have really good code, even if written by a racist or sexist, than bad code (period). Again, I'm not sure we have to make that choice.
"We value creating wealth over capturing wealth."
What does this even mean? This is a programming language, ffs. Your statement makes sense in, say, the heyday of APL or Smalltalk or some other very vendor-specific language, but that's not quite the case today. Are you talking about not doing data-mining to monetize your fellow man? About not creating yet-another analytics or ad platform? What then, exactly, are you driving at?
"We value teaching, learning, and improving our craft over short-term productivity."
Again, not mutually exclusive. Also, part of learning and improving your craft is knowing when a quick hack is the right answer instead of a full solution.
> I'd rather have really good code, even if written by a racist or sexist, than bad code (period).
That's a perfectly valid choice. In some cases, it's a completely correct choice. But that's not the tradeoff that I want to make.
Take a look at the original Agile Manifesto: http://agilemanifesto.org/
Sometimes you can have it all: good process, good tools, good individuals and interactions. But when they conflict, the AM says that we should favor the individuals over the processes.
I'm saying that as a development community, we should favor inclusiveness and respect, even at the cost of (some) technical merit. Similarly, we should favor open-source infrastructure, even at the cost of the App Store audience.
When choices are available for a software library, pick an open-source one over a well-tested black box, and perhaps even contribute. If the black box is the only reasonable thing out there, then use it.
Rather than try to hire by a strict ordering of skill, create an environment with varied viewpoints that can all be heard. (Of course you still hire among the top candidates, and avoid bad coders)
When choosing between two jobs, one of which creates a new product that people love, and the other cuts into someone else's profits through algorithmic/technological superiority, pick the first one. If you don't have such a choice, it's not relevant.
Last one I'm not sure about, but one possibility is "go learn Haskell/Lisp or experiment with the latest algorithms/libraries in the evening rather than work 18 hour days for your job." If you really have to get something done for work, by all means do it.
It's not "always do this", but rather "when you do have the freedom to choose, pick this"
"We value X over Y" is not a trade off, it's a dogmatic claim.
"We should do X in these conditions and Y otherwise" is a trade off.
For each of the items you list above, I can come up with a few scenarios where doing the opposite of what the Agile Manifesto says would be the better approach (and that's probably one of the main reasons why hardly anyone takes that Manifesto seriously these days).
For example:
Processes and tools can often be one of the best ways to improve interactions among individuals. See Scrum, which is hardly a panacea but sometimes it works wonders.
For a large project, comprehensive documentation is essential to producing working software. Ideally the documentation should be so comprehensive that it pervades the very fabric of your application in the form of good factoring, command-query separation, etc.
Contract negotiation can be an important first step in customer collaboration. Everyone needs to know where everyone else's needs, boundaries and comfort zones are.
Without a clear plan, how can you be sure of the best way to respond to change? See: Duke Nukem Forever, WinFS, RIM.
"I'm willing to give up some valuable-thing-Y in exchange for more X" is a textbook example of a tradeoff.
Heh, until not long ago a "meritocracy" was seen as something good and desirable. Nowadays it seems to be something bad (at least in some circles). Funny how things can change.
"We value readable code over runtime performance."
It might help if the manifesto is clearer on what you don't value. Mission and vision statements are often meaningless because you can stretch a positive statement to include almost anything. The Agile Manifesto is great because it uses contrast to clarify what it values most.
In some of the statements, the contrast seems to be implicit and that's fine. ("I value an environment conducive to all levels of experience." I assume that means we don't want an environment for only beginners or only experts.)
Other statements, though, are harder to figure out. ("I value software development as a craft." Does HDD cater to "craftsmen" as opposed to hobbyists? Or is this in opposition to "professionals"? Or are we talking about relationships and apprenticeship?)
I think this concept has a ton of potential. Can't wait to see where it goes next.
EDIT: It appears tmorton was thinking the same things and used far fewer words to say it.
Maybe it's just the lack of a corporation pouring billions into it like google did with V8, but I suspect that ruby can never be fast, due to ObjectSpace and the like. That awesome/insane object model we all like so much is just impossible to optimise. All the other weird shit ruby can do doesn't help.
http://blog.headius.com/2012/10/so-you-want-to-optimize-ruby...
Still, for stuff that doesn't need to be fast, ruby is still a joy to use, and always will be. The enumerable API feels so fluid, it's only really surpassed by languages like clojure in my experience.
As you might be able to guess, I'm looking forward very much to swift becoming a general purpose language. If apple are all funny about it and try and neuter the ecosystem for some reason, I will be a sad panda.
Ruby has been a major source of improvements in software, especially tooling and web development, over the last 10 years. A lot of the newer languages have borrowed concepts popularized by Ruby (gem-style package management; bundler-style dependency management; same-language build tools like rake; rails and sinatra-esque web frameworks). And a lot of tooling for other languages has been written in Ruby (sometimes later replaced by same-language tools). I'd compare the role Ruby has played to Perl in the '90s.
I certainly hope Ruby doesn't go down Perl's path. It may be protected from that fate by two differences. First, there's no Perl 6-like project to distract attention and effort from the actively used version. Second, Ruby remains by far the best general-purpose language out there for those of us who like Smalltalk-style OO languages (everything an object, message passing, extreme late binding).
I too would really like to see Swift escape the Apple ecosystem, for a number of reasons, even though I'm unlikely to use it myself.
Node.js demonstrated the power of V8 with an alternate stdlib, perhaps an alternate language in front is possible too? Then again, probably V8 is at the very least heavily entangled with Javascript's type-system.
Last I checked, V8 was highly JS-specific, and you would have to rip out and replace large parts of it.
[1] https://trac.webkit.org/wiki/FTLJIT | https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-... | http://blog.llvm.org/2014/07/ftl-webkits-llvm-based-jit.html
The JVM boot time is a bummer, but beyond that, there's not much to complain about.
So, one immediate solution that would drive again Ruby to a stellar embracement and adoption could be preserving, in development, this immensely useful hyper-reflective environment which gives us hyper productivity and then have a parallel production environment where all of this is stripped down and code compiled without it.
In the wait for better solutions this could be a possible path, and I am sure a lot of people and software in the Ruby ecosystem would still prefer to adapt to this, rather than having to code in a more performant but ugly language.
I'm not sure how happy you should be as a self centered developer with no empathy for the people using your software.
Sometimes software can and should be ugly if it makes for a better end product.
What does that even mean? If a Time Cube guy shows up, does it mean I'm just supposed to politely ignore/shadowban him?
Does it mean I can't use "master-slave" replication?
I think what that line is supposed to mean is "I value not being needlessly abrasive to people" and "I value ignoring unrelated-to-my-project aspects of people".
That is, even if you have some belief or participate in an activity that I find abhorrent, if it's not relevant to the project we're working on, I value avoiding talking about such things so we can focus on the project.
For example, the principle that a programming language should be optimised for the programmer and not the computer seems reasonable. However, what if a programmer works on projects where performance matters, and we haven’t figured out how to implement certain language features in an efficient way yet? It may be true that under some conditions saving a programmer time is more valuable than shaving a few seconds off at run-time, but there are many situations where this is not the case.
More subtly, programming languages that are easy to parse, that represent their source code in a well-structured way, and that have clean semantics are friendly to tool developers. I imagine many programmers are happier with a language that has good refactoring, debugging, profiling and testing tools available, and which plays nicely with their favourite editor, diff and version control systems, and code review tools. Again, there might be a trade-off between adding a new language feature, which in itself might be useful for the programmer, and keeping the language simpler or more cleanly structured, which might encourage effective automation and tooling.
I love Ruby and the Parallel gem (https://github.com/grosser/parallel) makes certain stuff easier, but I feel like every month or so I spend hours just trying to figure out the proper way on how to parallelize
It has semantics very similar to Ruby or Python, but it has strong built-in language-level support for parallel computing: http://docs.julialang.org/en/latest/manual/parallel-computin...
Just Perl made string manipulation a lot easier then the standard shell. Also Perl got there first, which is slightly important.
For example, when shelling out, ruby lets you do it many ways, including the familiar backtick syntax. In python, you shell out with popen -- you need to contruct argument lists, wire up stdout and stderr, etc.
Python's way might actually be better (more explicit, less ambiguity, easier to handle errors) but often you might just want something that's simple and readable.
For the record, there are nicer python APIs and safer ruby APIs. These are just general comments on the different ecosystems.
True preemptive multitasking probably also helped.
AppleScript doesn't come close, and on Windows sketchup is the only app I know of with anything similar, which happens to be Ruby. But you can't create great workflows in an ecosystem of 1, and I expect that ship has long since sailed.
What are some examples?
I'll start with heavy number crunching (Go/C) and browser-based apps (JS)
There are also some great gems like Celluloid to help. That said, it's not the same as built-in concurrency.
http://madebymarket.com/blog/dev/ruby-web-benchmark-report.h...
Be careful to distinguish between the language and a particular implementation or runtime environment.
Go, for example, runs perfectly well in the browser[0] except for channels (which are very difficult to implement reliably given the Javascript concurrency model).
If Google decided to allow Go as a language for manipulating the DOM in Chrome, there's no reason that it couldn't serve this role equally well. (This is what Google has done with Dart, so they're unlikely to do it with Go, but this is simply illustrative).
Lend your two cents in the comments...
But I don't like that it starts with a machine and code focus. Shouldn't people be first?
I've always viewed computers as lowly tools meant to do my bidding, so I don't really understand this sort of emotional attachment that people get, but it's definitely a real thing that people feel. The only pragmatic way forward is to accept that this happens and figure out how to incorporate it into the larger context of software engineering.