Weekend warrior – MacRuby and rSpec, Mac OS X Lion, Xcode V4.3.2

Inspired by the recent buzz over RubyMotion, of which I am a proud licensee, I wanted to play a little with MacRuby just to get into the swing of things.

After deciding that doing so was more worthwhile than to mow the lawn, I set out to see what it took to start a project in MacRuby with rSpec support as a basis to start work.

MacRuby’s article got me started, but did not work because the test target could not find the framework that I wanted tested. I don’t know why, since I (sort of) follwed the instructions there. I say “sort of” since the article shows screen-shots of an older Xcode, and even though I thought I set things correctly in my version (Xcode V4.3.2), it still would not build. Also, I am on Mac OS X Lion and that may have had something to do with it.

After realising that if I did not continue trying, a certain member of the household would make me mow that lawn, Google found another article here by Steve Madsen.

It too looked promising, but again, needed tweaking to get working in my environment. It’s thanks to Steve’s post that I managed to get it working.

Here were my steps:
a. Create a new project in Xcode (or use an existing one that you want to rSpec)
b. Install MacRuby
c. Follow Steve Madsen’s instructions

At that stage it still did not work for me, but that was because of a misunderstaning that was clarified quickly enough:

Steve’s screen-shot for the scheme settings on the Specs framework is cut off and does not show the “Expand Variables Based On” setting, so $(SRCROOT) was never expanded for me. I replaced it with an absolute path (ugh) and it worked, so I knew something was not picking up that macro. The solution was to give a value to that drop-down, as shown in the screen-shot below.

If, like me, you’re on Xcode V4.3.2, you might find the following screen-shots useful (just refer to them as you follow Steve’s post):

a. Build settings:

b. Scheme settings:


You cannot imagine the joy of seeing Ruby code drive an Objective-C framework testing session using rSpec in Xcode.

Now to that mower…


DDD – Document Driven Development

We rarely document. We are used to being handed a set of PowerPoint slides that describe, on a very high level, the business need for software. We roll our eyes at the slides, and get to work, asking questions, clarifying the needs, hope to understand them and start imagining features and how we can deliver the implementation within the requested timeline.

If we follow the Agile framework, we’ll translate the transformed slides into stories. We do so and derive tasks from them. If we’re lucky, we might be able to condition the business to accept deliverable milestones that are aligned with those stories.

Using BDD, we’ll transcribe the stories into Gherkin and using TDD, we’ll start coding tests at that time (rSpec, Cucumber).

As development gets under way, we cycle through iterations and we deliver collaboratively.

After the celebrations, all the good things mentioned above (stories, milestones, BDD, TDD) evaporate as the project starts gliding at low altitude as the business moves to new territories. We’re left with mundane maintenance and tickets are opened for small bug fixes and minor enhancements. Stories are no longer written as “it’s not worth it” and small changes are never fully documented.

The project stops being documented and over time, as the team members rotate and business rules change, people no longer remember why we check-off the ‘accept contract’ terms after signup and not on the page where the user enters their email address. It so happens that there will be a major impact on the back-end provisioning system if we change that.

I think the pattern is clear – If we don’t use our documents, the whole eco-system of our product degrades to entropy and will ultimately lead us to revival by rewrite, or at least by going through the analysis again and likely to some re-engineering. Time wasted.

What I would love to see is a system whereby the development and maintenance is driven by documentation and that the documentation drives the deliverables.

The pieces are there, we just need to use them:
Participate in the requirements phases, translate them to stories, deliver story implementions. Always, recurringly. Never stopping this cycle.

Months from now, anyone reading your stories will fully understand why the system behaves the way it does – people like to read stories and will understand the system on their own terms. New hires in the business will use them as a guidline on how to perform their jobs. New developers to the team will have a standard to meet when fixing bugs or evaulating new or changed requirements.

We will end up with a document-driven system, accumulating a library of living documents that drove our software development effort. Any new contradictory story will violate the automated validations for previous generations of stories and will stop us in our tracks, showing us exactly where the business flow will break if we add that new feature. No one actually needs to know this in advance: Let the business tell new stories and see how the system reacts. It’ll tell us whether we’re in violation of any existing processes and alert us automatically.

If you’re using Gherkin and Cucumber already, put them front and center of your development workflow and don’t let go of them!


The tip of the (good) iceberg

Recently, a “perfect storm” situation occurred when we realised that there was a convergence of a new business need with an old technical need.

We have a technical issue that we wanted to deal with for a long time and yet never got to it because of high-priority tasks requests for the business. Our issue has to do with overhauling data structures and internal SOA processes to be more flexible and to be able to support business requirements in the future. The tasks and migrations were analyzed and estimated at “medium” and “hard” complexity levels and felt like an elephant in every meeting concerning the project, which is a central one in our business.

The “perfect storm” appeared when the business unit requested a feature that was solved by our internal analysis as part of the overhaul, but the key factor was that they asked for an initial implementation where only 20% of the customers be effected.
We were confronted with a situation where both parties had the same goal – we had technical justifications to make what we saw as needed changes and the business unit had a market-driven justification for asking for changes. This is a perfect situation to be in as both units are aligned and there is no conflict of interest.

The beauty of the situation is in the “20%”. By requesting that only a selected 20% of the customer base be affected, we could now picture the technical scope of the project with a different mindset – one of depth of development for a limited breath of the customers. By this I mean that we are able to plan for the “most value” for the business unit – producing working software to solve for the 20%, while back-filling the rest of our technical debt towards this project by the current processes till more is developed for the next segment of customers. True, there will be “production support” till we achieve 100% customer base, yet solving for 20% economically justifies that cost and effort.

The result is that the business unit will see only the tip of the iceberg of this project with immediate value, while we work on the invisible part that will cover the subsequent market segments that will be addressed sequentially over time.

The convergence of the business goals with ours makes it possible for us to succeed with this project and introduce it to the market in small segments. If only all business and technical requirements were so well aligned!