An IDEAL development environment

I've spent a good part of my life thinking about software tools, and the last four months doing a deep dive into the new generation of web tools. And I think I know what I want to build. So here goes.

First: I want to start with the smallest core I can.
Second: I want to be able to build all extensions using the tools themselves.
Third: I want to have the tools mange the process of extension building. That is, I want to be able to describe a unit of work (which may involve changes to various parts of the code base) in one place; that one place will include relevant documentation, as well as code. It will also include tests and other metadata as I figure it out.

After surveying the field I've made the following design decisions:

• The UI will be browser-based
• The development framework will be built on Brunch, which includes
• NodeJS
• Which includes NPM
• Coffeescript
• Backbone, which includes
• Express
• Underscore
• LESS/SASS/Stylus
• Jade/eco/Handlebars/mustache
• JQuery and JQueryUI

Why this combination? As we'll see, it provides a framework that support some important ideas that I have about programming. I want:

• A simple client/server architecture with an easy way to change both sides. NodeJS gives me that
• An expressive notation for my code that makes it easy for me to create Domain Specific Languages for my tasks. Coffee does that
• Simple, expressive notation for markup with jade or  Source HTML clutters my screen (and my mind) with unnecessary characters and constructs.  Jade/eco/Handlebars/mustache handle that.
• Simple, expressive notation for presentation style. CSS is great but it clutters my screen. LESS/SASS/Stylus get around that 
• A sensible predetermined directory structure for my application. Brunch does that

Becoming a Software Professional

In most areas of sport (and life) a professional is one who gets paid; an amateur is one who does it for free and for fun.

Steven Pressfield tries to define the difference in The War of Art:

The amateur plays for fun. The professional plays for keeps.

To the amateur, the game is his avocation. To the pro, it’s his vocation.

The amateur plays part-time, the professional full-time.

The amateur is a weekend warrior. The professional is there seven days a week.

I think he's got it wrong. There are plenty of programmers who don't "play for  fun," who program as a vocation and not a hobby, who work full time, and who are there, often unhappily, nearly seven days a week. That doesn't make them pros in my book.

To me the difference has nothing to do with money or love. It's a different attitude:

• Amateurs go through the motions, professionals focus on what they do.
• Amateurs are satisfied with good enough; professionals push the limits.
• Amateurs just do their work; professionals do their work and study it.
• Amateurs see their work as an isolated subject; professionals tie nearly every field of study to their work.
• Amateurs exercise skills; professionals exercise them--and practice the most important ones.

Thinking about this, I'm halfway between amateur and pro--and I'm now determined to be a pro. That's what this blog is about.

What’s this blog about?

Software Economics is about the costs of developing software and how (and how not) to reduce those costs.

It’s also about what makes software valuable, and how (and how not) to make it more valuable.

This blog is the result of musings on the subject that I’ve had over a 40+ year career in software, and some recent, intense investigations.

I hope that it will help me organize my thoughts and focus my investigations.

I also hope it will provoke some good comments and new ideas from readers.

It’s based on the following hypotheses and questions—and no doubt will surface others.

Technorati Tags: Economics,Goals

• Most companies are not very good at developing software—but some are great. What can we learn from the great ones?.
• Most programmers are not very good at developing software—but some are great. What can we learn from the great ones?
• Most companies that are trying to improve software development are going about it the wrong way—but some are doing it well. What can we learn from them.
• How would an individual (me, for example) go about dramatically improving their own software economics?
• How would a manager go about it?