Friday, October 03, 2014

A Rails Enthusiast’s take on MEAN.js

Is MEAN.js Node's answer to Rails?  Following the famous blog demo creation using the MEAN.js stack.

How does developing with MEAN compare to that first Rails app?  Pretty fairly, as I found out.

This is an article I wrote for InfoQ:  http://www.infoq.com/articles/rails-to-mean-js

Friday, August 22, 2014

Monday, February 10, 2014

How to get good software from contractors

OR Working with codecraft (me)

I think I have said before, the purpose of software development is to produce good enough software as quickly and efficiently as possible.  Everything I do at codecraft is driven by that principle.  But why just "good enough," and what does it mean exactly?

Good Enough Software

The software created by a project should only be good enough, not more.  That sounds crazy, I know.  But, if we are trying to get to market quickly and make strategic use of our investments, any bit of extra quality or premature scalability or speculative functionality costs money, money we could spend elsewhere.  One has to be serious about how time and money are spent or the competition will clobber you.

Good enough, then, means finding the balance between present and future costs and benefits.  Good enough means investing in what you need most right now, while being conscious of future concerns.  Good enough means getting something inperfect in front of users quickly, and worrying about scale and perfection when the system is viable.

So how do I go about delivering Good Enough, quickly and efficiently?  It is all about providing rich, continuous feedback.

What I Do

Continuous Planning
Every day, the plan will change to respond to where we are and what is the most strategic use of time.  I usually like to keep a prioritized "feature inventory" in a shared document of tracking system.  The client picks priority features, with some elaboration and discussion as necessary, and defines "Stories," pieces of the feature that make reasonable units of work.  Stories move from a Ready state to In-Process with further discussion as necessary, and using the principles of Kanban the in-process work at any time is limited to hone productivity.  Completed code for a story is captured in the shared repository when finished.

Continuous Communication
Using a tool like Campfire or Flowdock, the entire team can share and recall group communications.  Developers will be available continuously (during certain time frames) in this environment.

Continuous Quality
All business logic modules will be supported by automated unit tests and shared with the client as desired.  The user interface will be supported by a reasonable suite of integration tests.  The full test suite should be run before every commit.

Continuous Delivery
All completed source code is kept in a shared repository like GitHub and available at any time to the Client.  I would suggest we use a cloud or PaaS like Heroku or Digital Ocean to host a couple environments, "staging" and the ultimate live site.  As soon as possible, the running application will be available in staging.  Every bit that is committed into the shared repository will immediately be installed into the staging environment for review.  Code is often delivered several times a day.

What I Don't Do

I don't tell you what you want to hear.  I don't pretend to see the future and act like I know what the optimal solution for the client will look like, months from now, much less how much effort it will take.  After all, Estimation is Evil.
Rather than basing the relationship on a contract that gives clients a false sense of security about getting what they need, I prefer to set up a relationship based on trust.  Trust at a personal level, but more importantly a trust in the practices that we will set up together to ensure the best possible use of time and resources.