data = %w/file edit search view tools options language buffers help/

class Array
  class Iterator
    attr_accessor :cc, :next_cc
    attr_accessor :value, :next_value
   
    def next?
      @next_value
    end
   
    def next
      @value = @next_value
      callcc do |cc|
        @next_cc = cc
        @cc.call
      end
      @value
    end
   
  end
 
  def iterator
    @iter = Iterator.new
    callcc do |cc|
      @iter.next_cc = cc
      each do |obj|
        callcc do |cc2|
          @iter.cc = cc2
          @iter.next_value = obj
          @iter.next_cc.call
        end
      end
      @iter.next_value = nil
      @iter.next_cc.call
    end
    @iter
  end
end

iter = data.iterator
puts iter.next while iter.next?

There are significant underlying reasons for the difficulties of software development, especially in enterprise environments:

• Hard-to-understand legacy systems.
• Highly complex business domains such as investment banking.
• Stakeholders and business analysts who don’t actually know what they want.
• Managers resistant to productivity because it shrinks their yearly budgets.
• End users who actively sabotage your project.
• Politics! Sticking your head out means worrying that it’ll get chopped off.

As a consultant to Fortune 1000 companies, I lived and breathed those situations on an everyday basis for almost 10 years, eventually stumbling upon a powerful concept.

• Developer motivation and productivity trump all other factors for project success.
• The best way to keep motivated and productive is to focus on delivering business value.
• Performance means “executing as fast as possible, on a given set of resources.”
• Scalability means “executing as fast as needed, on as many resources as needed.”
• Performance is irrelevant if you can’t scale.
• If you can scale cheaply, milking every ounce of performance from your processors should never be your first priority.
• Linking scalability to choice of development tools is a pervasive mistake in the industry and most software does not have extreme scalability requirements.
• Performance is related to choice of language and tools because higher-level languages are easier to write and understand. There is wide consensus that the performance problems in most applications are caused by poorly written application code.
• Convention over configuration is a better way to write software. Huge XML configuration files must be eliminated!
• Code portability, the ability to take code and run it on a different hardware platform, is not particularly important.
• It’s better to solve a problem well even if the solution only runs on one platform. Portability is irrelevant if your project fails.
• Database portability, the ability to run the same code on different relational database systems is rarely important and is almost never achieved.
• Presentation is very important, even for small projects. If your application looks bad, everyone will assume it is written badly.
• Allowing technology to dictate the approach to solving a business problem is usually a bad idea; however, that advice shouldn’t be used as an excuse to stick with inferior technology.
• The benefits of generalized application components are dubious. Individual projects usually have very particular business needs and wildly different infrastructure requirements, making parameterized reuse very difficult to achieve in practice.