Archives

photo credit: alq666

As a software development company, we mostly work on client projects. Occasionally one project doesn’t start right when another ends. In that short interval, we would like to work on something useful — in house products, R&D projects, etc.. Unfortunately, we can’t run these “bench” projects the way we run a normal project. We can’t do two or even one week iterations, because some folks may only be on the bench for a few days. So, how do you apply these resources efficiently? Here are a few tricks we use:

1. Divide work into very small pieces — no epic user stories!
2. Keep your technology as vanilla as possible to reduce the learning curve.
3. Use Kanban to organize the work.

What is Kanban? There’s some good explanations of it over at Wikipedia and InfoQ, but just like Agile and the feedback loop, it helps to know the basic principles so you can figure out how it will work for you. From the InfoQ article:

A Kanban is a signaling device (usually a physical card in a clear plastic envelope) that instructs the moving or creating of parts in a “pull” production system, invented and developed as part of the Toyota Production System (TPS).

[...]

Kanban’s aim is to minimize WIP (Work-In-Process), or inventory, between processes by making sure that the upstream process produces parts only if its downstream process needs it. “Pull” means that the downstream workers withdraw or “pull” the parts they need from their upstream processes.

So, the basic principles are “pull” and minimizing “work-in-progress.” Let’s see how this applies to the bench.

Eric Smith from 8th light gave a hands-on TDD presentation at last night’s Chiphone meeting, hosted at Obtiva’s downtown office, (conveniently located near the the train).

There was a good crowd of people, most attendees have ‘played around’ with iphone development, 4 have actively developed apps (3 people have live apps in the store).  From my quick survey of those that have submitted apps, it seems most of them were free utility apps or simple games, with at least one commercial app Dash for Confluence. It also seemed that no one had yet needed to do any animation beyond the basics, with just a bit of core-animation, but no need for more lower-level openGL or animation engines.

Eric started off by saying that he’s given talks on iPhone testing, but that just telling people what to do is not the same as letting them experience it for themselves,  so we did a Randori, where a pair starts working on some code, and every 3 minutes one person from the pair swaps out and chooses his replacement from the crowd.

What I liked about this was that I felt like I got to know the audience better, and actually watch people reason their way through the code or a testing/mocking issue.  (You know how sometimes you go to a user group, and it can be hard to get a chance to talk to others, or sometimes there is a ‘know-it-all’ guy, and you just want him to shut up. Knowing that you are going to have to go up there and code is a great way to silence those types)

When it was my turn,  there was an interesting issue with one of the tests that had us all stumped for a bit, but ultimately ended up being one of those problems where you need to deconstruct everything and build it back up. (The issue was that while we were trying to set fooController.textView.text = @”foobar”, we hadn’t instantiated a textView object, or set it on the controller yet.)

To make a cheap joke and paraphrase a common quote, web developers and web designers are two groups separated by common languages. In our case, the languages are HTML and CSS, which are the output of both the web design process and the web development process. Developers and designers produce their HTML/CSS in different ways and with different goals. Here are some ideas for bridging the gap so that the developers and designers on your team can work together smoothly.

Designers and developers obviously have different goals for their HTML — developers have issues of reducing duplication, organization, and performance that are largely not the designer’s concerns. The designer is primarily concerned with how the HTML looks and behaves to the user.

Q: What is the NewNet?

a) The increasing prevalence user-generated information on the Internet
b) Push-web triumphs over pull-web
c.) Social media
d) An attempt to sell subscriptions to Om Malik’s new “research” service

Answer: d. GigaOm Pro: Fresh Internet buzzwords, unsullied by the taint of the latest crash. Can I have my Web 2.0 back, please?

On seeing that someone had developed a Grails Plugin for Vaadin (the former ITMill Toolkit, based on GWT as a front end technology), I immediately grabbed it and started exploring. One of the first things I do when developing things that look like GUI’s is apply PureMVC to it. It’s sort of like a big MVC switchboard that lets you hook together the smaller MVC’s of whatever framework you’re using. Overkill for really simple applications. Crucial for big ones.

Building a PureMVC app was pretty quick, but I ran into a small problem. Since PureMVC Multicore uses a Multiton pattern (essentially a map of Singletons), when Grails recompiles and restarts on code changes, the application barfs with a “Facade already constructed” runtime error. The solution is simple. In your subclassed org.puremvc.java.multicore.patterns.facade.Facade, change the following:

  public static ApplicationFacade getInstance() {
    if (instance == null) {
      instance = new ApplicationFacade(CORE)
    }
    return instance
  }

to this:

  public static ApplicationFacade getInstance() {
    if (instance == null) {
      // nuke the multiton so we can do the grails recompile
      if (ApplicationFacade.hasCore(CORE)) {
        ApplicationFacade.removeCore(CORE)
      }
      instance = new ApplicationFacade(CORE)
    }
    return instance
  }

And voila, your app now recompiles and runs without a hitch, just like a Grails app should. (CORE is a string constant to name your core.)

Related Services: Java Application Development, Custom Software Development

Mocha on sparklette.net

Mocha is the mocking library used by the Rails team, so it has understandably gained some traction among Rails developers. I have started using it over flexmock lately, but ran into some problems with partial mocks on ActiveRecord objects. The problem stemmed from the fact that ActiveRecord instantiates new records when returning records from finders, which meant that creating partial mocks for a particular record was difficult.

I created a helper method to make this easier, and so far it has cleaned up a bit of my tests.

One thing about agile teams is that they constantly strive to get better. In my experience an Agile team takes 2-4 iterations to work through the forming stage. By iteration 10 or so the team is past forming and storming and is well into norming. At this stage the team is often moving fast enough or better than expected for the business’ needs. Now the team faces a dilemma: How to become a high performance team and why.

If you don’t keep improving and innovating your competitors will.  However, there is another reason to keep improving that is often missed.  The current success might be temporary or an anomaly.

Don’t fall into the trap of a one hit wonder.

All the good stories in agile software development start “three manufacturing efficiency experts walk into a bar…” But seriously, I think it’s clear that software development has a greater affinity to manufacturing than to construction. So, its good to see the Lean and manufacturing folks get a little blog buzz over at AgileSoftwareDevelopment.com with Jack Milunky’s post The 7 Software Development Wastes – Lean series Part 5 – Motion:

Waste #5 in manufacturing is defined as Motion. And motion can be compared to “task switching” in Software Development – as defined by the thought leaders applying Lean thinking to software development.

[...]

I have found in many organizations, especially software companies where there is a real casual atmosphere, it’s easy to always interrupt developers. Interruptions are prevalent with requests. All this interruption only serves to add to the Motion bucket of waste. This is where the importance of a Product Owner, ScrumMaster and Backlog come in. These roles and any artifact are there to buffer the development teams from the noise and chaos outside of the current sprint activities.

Sometimes being able to reference another discipline, like manufacturing, lends credibility to discussions with a stakeholder. More often than not, many consider themselves to be an expert on software development but wouldn’t dream of challenging an expert on manufacturing.

Related Services: Agile Development, Custom Software Development

I’m approached by people every week that think they have a great “new” idea for a web startup.   The ideas run the gamut from those that aren’t yet technologically possible to those “new” ideas that I have received 10 similar calls on over the past year.   Here are some things to consider:

Think about the business need and revenue model first.  Who are the users (your “customers”), what is the application or service worth to them, how many of them are there, etc.   If you can’t envision generating a million dollars plus a year in SaaS (Software as a Service) revenue or in gross margin for an eCommerce business, it’s probably going to be an expensive hobby, not a business.

Make sure you can create a sustainable competitive advantage.  What are your differentiators?  If you have to say I want a site like “xxxxxx”, you are probably starting off on the wrong foot.   You already have at least one competitor with a customer base.  

Blue Ridge Mountains by eleda 1

So, I tried Blue Ridge for the first time yesterday and I thought I’d write down some quick impressions. Hence, Rails Testing First Look.

Disclaimer: We came into this tool so cold our toes froze. We fumbled, we made mistakes, we probably missed really great ways of doing things. I look forward to being enlightened.

Let’s do this question-and-answer style: