A couple of years ago I had the benefit of seeing agile contrasted against waterfall with the same development team on the same project. The team had recently delivered the 1.1 version of a global web application. The customer then took over the project by replacing the project manager and business analysts with people who had no agile experience.

Up until after the 1.1 release our highly productive team absolutely loved coming to work in the morning. We were eating up storing points with an insatiable appetite and pressure to perform came from inside the team. Frequently our roles would cross. Developers would help out Testers and BAs as needed and the Testers and BAs worked very closely together to document proper story acceptances.

When agile was dropped for a more traditional process, things deteriorated very quickly (teamicide). I noticed major negative consequences in user stories, project planning, management, and software development.

Stories

The agile team that was together from inception through release 1.1 benefited from testable stories with high value features. Developers worked with Business Analysts to identify tasks within a story that would require significant development time so that the Product Owner could make informed decisions on whether or not a particular feature provided enough business value to warrant the cost. The BAs also enjoyed lower cost alternatives provided by developers. Only minor changes to a story were allowed after a pair of developers started on it. Significant changes required a new story.

After release 1.1, pseudo-stories were created with many nice to have, but not critical requirements with no developer input. Story requirements changed throughout the iteration including after the story delivery.

Planning

The agile team assigned points to stories during the inception. The amount of points completed during an iteration determined the team's velocity. The average velocity over the last two iterations was used to predict release dates.

The new project manager on the post-1.1 team planned out the next four releases in Microsoft Project with no input from the developers. The releases had unrealistic delivery dates for features that were not yet defined. This is the classic "phony deadline" technique used by managers to (de)motivate developers.

Project Management

The agile project manager was deliberately inattentive to enable the team to self-organize. This resulted in very high morale because developers felt free to contribute ideas and felt a sense of project ownership. The agile project manager's primary role was to remove obstacles that would otherwise distract the team.

The new project manager micromanaged all aspects of the project. We continued to have a stand-up every morning, but as each person gave a status, the PM would ask further questions like "how much longer until the story is completed?".

Development

Pre-teamicide, pairing time was protected, the velocity was high, the code quality was good. Pressure to perform came from other developers. All of this was achieved a sustainable pace with little or no overtime.

Post-teamicide, development time was highly fragmented through frequent meetings, phone calls, and IMs. The velocity was very low and pressure to perform came from the project manager who had set unreasonable deadlines. Large amounts of overtime were required, which led to many more bugs in design and code.

Conclusion

This project thoroughly convinced me of the effectiveness of the agile methodology. It was a great learning experience, but I hope it is not repeated!

Related posts:

1. You Shall Know Our Velocity!
2. What should a good iteration contain
3. Does your project have Code Ownership Culture?

photo credit: victoriapeckham

We have reached the most critical point on a project I'm working on. After a few months we think we know enough about the domain and application to build a product road map that will take us to the first public release. The proof of concept is complete. The design team has created a remarkable, genera changing product. Additionally, the system is designed around real users we have been able to talk to and get feedback from. We have put together an unbelievably good development team and built a backlog of stories with estimates. We have been here before. Putting together a design and backlog of stories is something we have done countless times...

The easy part is over. Now the hard part begins.

Our research and user feedback tells us we have multiple potentialcustomer groups we can build the system for. On one hand this is great news. We have a number of potential markets to choose from. On the other, we don't have an infinite amount of time and money to build it for all of these groups. We have to commit and go all in with one group. Right now, these are just some of the questions we are asking ourselves now:

• What customer group do we value the most?
• What features do they value the most?
• How expensive is it to build the ultimate product for each group?
• What is the minimum viable product we can build for each group?
• Which group is most likely to give feedback and partner with us to help refine our product?
• How much feedback is this group likely to give you?
• Are we missing some market window by passing on one group v.s. another?

This is a critical point in the product's design. Whichever user group we choose will be our customers. Or another way of saying it: They will be our ONLY customers. Other customer groups aren't likely to be interested because we aren't building any features for them yet.

When designing a product do you consider what customer groups you are including and excluding? Are you going to be happy with that choice for the foreseeable future?

Related posts:

1. Your SDLC or Your Product – You Decide
2. User Driven Product Development
3. “Build half a product, not a half-assed product” – tips on clarity and focus from Jason Fried of 37Signals

acl9 is a an authorization library for rails applications. It is one of the widely used library if not the most widely used now. Our experience with acl9 shows that it might be heavy weight if your authorization needs are simpler (which most projects are) but could be useful for other projects.

If you've used acegi/spring-security for authorization in your java apps, you know that acl9 is very similar in principle and hence very powerful. In addition to primary roles, it provides object level permissions which are stored in a generic way separately from the objects being controlled, all without the need for handcoding/distributing your authorization columns in each authorization-object tables.

One place where acl9 differs from acegi is how it doesn't differentiate between a role and a permission. Acegi signifies roles as global permission level which allows you to do certain things (some action on any object of a given class). Where as, a "permission" controls whether your can take that action on a certain object of a class or not. Acl9 calls them all "roles" (primary-roles and object-roles). As you can imagine, a given user may have a few roles in system but end up with lot and lots of permissions in system depending on how many objects user owns etc. This may seem like good idea at first but it presents a unique problem which is not apparent at first. Since roles and permissions are not conceptually separate in acl9 - and that a user can have lots of them (few roles and lots of permissions) - prevents us from loading and caching them in memory. Why do we need to keep them in memory? Because you are querying user's primary roles most often in your rendering of pages.

For example, consider navigation-bar which is common in most applications. Different users are presented with different tabs in navigation-bar and this bar gets rendered on each request/response cycle. Whether to render a particular tab is conditional to whether a user has certain role (primary role in particular) or not. Since acl9 cannot keep all roles (and permissions) in memory, it has to perform database query every time it has to find whether a user has_role?(admin) or not. Given that there can be only a few primary-roles that the user will have in any system, it seems in-efficient to not cache them and go to database each time.

The solution would be to separate these primary-roles from permission-roles and cache them for each request. In acl9 this means overriding User.has_role? and user.has_role!.

class User
  def has_role?(role, object = nil)
    if object || !Role.primary?(role)
      super
    else
      primary_roles.collect(&:name).include?(role.to_s)
    end
  end

  def has_role!(role, object = nil)
    super
    @primary_roles = extract_primary_roles if(Role.primary?(role))
  end

  def primary_roles
    @primary_roles ||= extract_primary_roles
  end

  def extract_primary_roles
     self.role_objects.select { |r| r.primary? }
  end
  private :extract_primary_roles
end

That does it. You cache the primary-roles and leverage those for has_role? queries.

Related posts:

1. Testing various roles in ruby on rails
2. The Truth About Designing For Security
3. Openfount Library Revisited

photo credit: moonlightbulb

I started my first real Agile software development project in 1999. I'd been doing more traditional software development before then all the way back to 1980. I won't bore you with the details of those earlier projects, but my feeling was that there had to be a better way of developing software that didn't involve a senior technologist (me) telling a whole bunch of junior technologists what to do. It turns out I was right.

I started my first real Agile software development project in 1999. I'd been doing more traditional software development before then all the way back to 1980. I won't bore you with the details of those earlier projects, but my feeling was that there had to be a better way of developing software that didn't involve a senior technologist (me) telling a whole bunch of junior technologists what to do. It turns out I was right.

But almost from the start I got pushback from other people in the development organizations I worked in that Agile development was horribly wasteful. They pointed to Test Driven Development ("all those tests more than double your effort"), pair programming ("two developers doing the work of one?"), and refactoring ("you're rewriting the software every time at enormous cost"). Of course all of these objections were born not just out of a misunderstanding of Agile development, but a fundamental misunderstanding of how their own software development processes actually worked.

The issue of refactoring was particularly mysterious to my colleagues. If you took the time and designed software properly up front, they reasoned, you won't have to do expensive rewrites. Of course anyone who has ever maintained code knows that this isn't ever true. All code, regardless of how it is developed, changes over time for bug fixes and to meet the needs of new requirements. If you aren't thoughtful about how you change your software, you can easily end up with a big mess. Further, very little software is design with a perfect understanding of the requirements, leading to imperfect designs and things like the second and third system effects.

If you are thoughtful about how you change your software and think about the sorts of "code smells" that crop up in your code over time, you end up making more fundamental changes, rather than adding a method here or a instance variable there. You might see that two methods are always called in conjunction and decide they should be folded into one method (a design win, see State Patterns), or you may have extended your design and ended up with two parallel hierarchies of classes. You break the Go4 glass and pull out the Bridge Pattern to solve that burgeoning design problem. Through constant refactoring (or rewriting, take your pick) you avoid painting yourself into a corner as your requirements change.

The fact is that good developers are constantly redesigning and rewriting their code. Those same developers will tell you that the longer you leave problems (technical debt) before refactoring, the bigger and more expensive they become, until you might be better off just scrapping the system and rewriting from scratch.

Agile development takes this normal refactoring to it's logical extreme. Rather than doing a big design up front and then doing a series of expensive changes when they are inevitably found to be wrong, Agile teams accept that their design will be imperfect and then build comparatively inexpensive refactoring into every iteration. It may seem counterintuitive, but all that refactoring results in code that is cheaper to develop, easier to maintain (because it's easier to understand, change and debug).

Among professional writers the golden rule is that the key to all good writing is rewriting. The same is certainly true of software.

Related posts:

1. GWT and the Static Versus Dynamic Religious War
2. Has Many has_many: A Refactoring Story
3. Requirements Set in Stone and Software Made of Concrete

Claude Shannon

So, it's little Stevie Jobs' birthday today. Certainly he's been influential in the world of digital computing. But when folks wax on and wax off about how great some of these more recent figures in computing have been, I like to remind them of some of the all-time greats. It just so happens that that today is also the 9th anniversary of the death of Claude Shannon. Who is Claude Shannon, you ask? How soon they forget, or perhaps they never knew.

Well, in his masters thesis at MIT in 1937, he observed that you could solve Boolean algebra problems using switching and relay circuits. OK, think about what that means. Wait for it...yes, he invented the modern digital computer. In 1937. In a masters thesis.

It was all downhill from there, of course. He only founded the field of Information Theory (central to cryptography, computational linguistics, and pretty much any kind of digital information processing). Yes, the digital revolution started with him.

Oh, and he also laid out the field of computer chess in 1950, describing the different ways a computer chess program could be designed. Sixty years later, his roadmap for the field has been dead on.

So, the next time someone celebrates Stevie's birthday, let them know about Claude Elwood Shannon.

Related posts:

1. Higher Order JavaScript
2. Why Computers are (aren’t) Better Than People at Playing Chess
3. March of the Games

The gem calculates the APR and monthly payment for a mortgage in the United States.

Calculating the monthly payment is straight forward.

C = Loan amount

E = Extra costs

r = monthly interest rate = interest rate / 1200

N = amortization term in months

An iterative approach is needed to find the APR. The equation for the APR follows.

a = APR/1200

N = amortization term in months

P = Monthly payment (including all fees paid by borrower)

C = Loan amount

The following graph shows the APR calculation plotted for N = 360, P = 2500, and C = 400,000. The APR is where the line crosses the A axis.

I chose the Newton-Raphson method to quickly find a precise solution.

The MortgageUtil.calculate_apr method provides a starting value of the interest rate, which makes the Newton-Raphson converge on a accurate solution between 1 and 3 passes.

Installation

% sudo gem install gemcutter

% gem tumble

% sudo gem install mortgage_calc

Example

Related posts:

1. Launched: Rapid Reporting Employment Chek
2. Installing Edge Ferret/acts_as_ferret
3. Rails Performance, Code Metrics, and Locking Down your Application: Tips & Tricks from Windy City Rails 2008

photo credit: Rich B-S

Gwarred Mountain over at Climax Studios has posted a very thoughtful blog post about software development methods and the appropriateness of Agile Software Development. I was ready not to like this article, what with the title and things like this:

If I have to sit through another meeting with some little "agile" toe-rag defending their train wreck of a project then I may end up forcibly ramming a kanban where the scrum does not shine.

But then I thought about all of those fresh-faced management consultants we've run into recently -- who have read a book about agile -- trying to teach us how to do it. Well, yes. I've had some uncharitable thoughts myself.

Surprisingly, I felt myself agreeing with most of what he wrote. No, Agile is no panacea. Yes, it works best on small to medium sized projects. Yes, you have to have an experienced team to do it well. Yes, there are other methods that are more appropriate in some cases and, yes, you have to recognize when to use something else than an agile approach.

His breakdown of people vs process is one of the many nicely coherent gems in the post:

So what is so great about process? Well, it gives us:

• Repeatable and predictable results
• Quality Assurances (through the above)
• Cost savings through the ability to optimise work flows
• Defined work flow allows us to use cheaper labour
• The promotion of best practices and conceptual integrity
• The ability to scale to large numbers
• A means to effectively track our progress against the objectives

McDonalds is a great example of successful process. No matter where you are in the world, you know what you are going to get and you get it quickly and cheaply. This process has successfully scaled to thousands of restaurants. Whether you consider this good or bad it is hard to argue with the results.

Nevertheless, software development is much harder than frying beef burgers. Process is sometimes inappropriate or unconstructive.

I'd say the lesson from his post is that you need to be thoughtful about the software development and project management technique you adopt. Know why you are doing things. Any process that has magical rituals rather than purposeful activities has a good chance of devolving into a software development farce.

There is one thing with which I take issue. He states that Test Driven Development (TDD) adds from 15%-35% to development effort. He cites an empirical Microsoft Research study. The paper, authored by Nagappan, et. al., is one that I am well familiar with. The study looks at four case studies, one at IBM and three at Microsoft, where two teams are given the same system to implement. Everything is the same except in one team incorporates TDD into their process. Neither team is told they are part of a study.

It isn't clear from the paper, but in my experience teams that adopt a new technique or tool usually are not as efficient the first time around. Certainly that is born out by our own empirical observations -- developers that are performing TDD for the first time are anywhere from 10%-30% less productive. That starts to move toward 0% after the first project. It becomes second nature. And as the study itself makes clear, the productivity losses in the study would be more than made up for in the maintenance phase of the software life-cycle, where 80% of software product costs land anyway.

Let's see, lower defect rates, no productivity loss after a little bit of developer training and reduced cost in the maintenance phase? Sounds like a no-brainer to me. Of course I don't know Mr. Mountain's industry. It may be that there is no maintenance in the game development space, just code and release. No updates. So rush to release, bugs be damned may be the best way to go (not being facetious here).

The fact that this study comes out of Microsoft already sets some alarm bells ringing for me. Although we're headquartered in Chicago now, we actually were founded in Seattle, physically and intellectually not far from the Microsoft campus. Based on what we saw working at and for Microsoft, we soon began a physical and intellectual journey away from there that has landed us in Chicago as a premier User Driven Software Product Development shop. We use experienced teams, User Experience Design (UXD) and are thoughtful about how and why we practice Agile.

We may not be everyone's cup of tea, but if you have a consumer or business software product or service that you need to get out to the marketplace swiftly, reliably and with high quality, then we may well be a fit for you.

Related posts:

1. Agile 2009: A reminder of why each team needs leadership
2. Agile Development and Play: Understanding the Value
3. Building a High Performance Agile Team: Assume You Will Be a One Hit Wonder

photo credit: World Economic Forum

It is very easy to misunderstand software and it's capabilities. Although people and software often perform the same tasks, they often do so in very different ways and achieve very different results. The results software can achieve are sometimes surprising, even amazing. But what computers can do is still quite limited. Making software development decisions based on an incomplete understanding on how software works, or drawing unwarranted equivalence between humans and computers, can lead to comical or even disastrous consequences.

It is with this in mind that I wanted to revisit one of my favorite topics: chess engines -- the computer programs that play a game of chess. Chess and computers were back in the news with a mainstream article by the mother of Kris Littlejohn entitled The Role of Computers in Planning Chess Strategy. Her son, Kris, helps current US Chess Champion Hikaru Nakamura prepare his openings for torunaments and matches and he makes use of various software (chess databases and engines) for this purpose. It's a well written article and well worth a read.

I've been an avid chess player for many decades and have also written a number of chess playing programs over the years. So it really tickles me how when then world champion Gary Kasparov lost to Deep Blue in a match back in 1997, many folks predicted that chess as a human past time would die. over a decade later, the situation is even worse for the humans: the best GM's can not hope to defeat the best programs, even at material odds. Yet the game is more popular than before. Part of the reason is online play thanks to the Internet. Another reason is that these strong chess engines make for primitive coaches. So the future of chess is safe for now.

But there is a bit of a misunderstanding on how chess engines beat strong human players. Early on, chess computers were considered curiosities, able to play a legal game, but not able to beat any but the most basic of beginners. That's because computers were slow, and the problem solving method they used -- tree search, a sort of "I move, you move, I move, you move,..." tree for all possible moves -- was inefficient. Also, the computers weren't very smart at figuring out whether a particular position they had reached was good for them or not.

Over time computers got faster, the programs first got better at searching less of the tree, then more of the really important parts, and they got smarter and figuring out whether a particular position was good. Eventually they started looking further ahead than most people do and got so that they played a pretty reasonable game of chess.

But when we say that a computer can beat the world champion, that's not quite the same thing as saying the computer is better. By way of illustration, let's imagine we are playing a game with your word processor. We take turns Stringing sentences together. First I write a sentence, then the computer writes a sentence. The sentences make sense, they talk about the same thing, they argue, explain and so on. Our sentences are better, more elegant, than those of the computer, since we have a more sophisticated understanding of language.

Let's suppose that we have one more rule. If either player makes a spelling mistake or a grammatical error, they lose. First of all, the computer will never do that. When's the last time your word processor misspelled a word? We, however, misspell words a great deal of the time. Also, we find our selves constructing sentences that end in a propositions. Crap! We lose!

That's how computers win a great deal of the time: they capitalize on a few human oversights and wins. Since I play against some of the best engines on my own computers from time to time for training purposes, I can verify that this is true. When I play Rybka 3, the currently strongest chess engine on the market, at reasonably slow time controls, I need to take back about 5 errors on average to win against it. I'm not cheating, I just get to correct some of my mistakes.

If you had made the mistake of thinking you could win against any human, any time using a chess engine, you might have entered a correspondence chess tournament (these days played on a web server instead of by mail or email), where people can take days or weeks to ponder over their moves, and placed a large wager on you computer doing well. And you'd be out a lot of money. The best human correspondence players don't make that many mistakes to begin with and also use chess engines to check the "spelling" on their moves. They would eat your poor computer alive.

So, lessons from this post? When evaluating the capabilities of software versus people, see how each arrives at their performance. You may be avoiding a big mistake.

Related posts:

1. Chess Game Viewer in GWT
2. Porting Java Libraries – Jazzed About GWT
3. Are We Engineering Software or People?

For a while there was a trend towards more and more purpose built digital products, from ebook readers to portable picture frames and pocket size digital cameras, all the way to to digital recipe readers ($299) and tablet pcs with tough cases, handles and barcode scanners for the medical industry.

The iPhone, the iPod Touch and the soon to be launched iPad signal a reverse of that trend. Apple has designed and built flexible platforms that combine the ease of use and simplicity that single purpose devices with the flexibility of general purpose devices, and that is proving to be a compelling value proposition.

On the iPad, for example, you can easily get as good or better a recipe reader experience as you would with the demy digital recipe reader, a better digital picture frame or slide show experience than with a digital picture frame, likely as good or better of an ebook reader experience, and likely as good or better of a bar code scanning medical tablet experience.

How is that last possible, when the iPad does not come with a bar code scanner? The solution will likely be through peripherals built into functional cases. As an example, take a look at the digital checkout devices like Apple's own EasyPay touch (used at Apple's retail stores), Verifone and Morphie - that combine a magnetic card reader, a bar code scanner and a battery in a case for an iPod touch.

And of course, when the video enabled iPad finally comes out, it will likely replace the Skype Video Phone that my parents so love.

Related posts:

1. Where the iPad will take over: 15 examples
2. Which Mobile Platforms Should You Target? (Part 2)
3. the iPhone and Touch screen technology

Tiling a Polygon

One of the most challenging problems I came across working on a .NET PDF Annotator and Editor application was to tile a 2-D polygon and also accurately determine the number of tiles that fill the surface of the polygon.  The tiling part was not as much of a challenge as the counting part. The tiled polygon was to be rendered on a PDF document since the application in question is a PDF Annotating and Editing tool. We looked for anything the third party .NET PDF rendering/manipulation API that was used could provide for the tile rendering but there was nothing unfortunately.

So we set out to use C#'s native GDI+ library to render the tiles for the polygon.  After trying out different approaches to accomplish the rendering of the tiles, we discovered the one that would work best. The idea was simple. Every 2-D shape on the drawing surface has a bounding rectangle that encloses the shape. Starting from the top left bounding point of the rectangle, iteratively render a rectangle (tile with whatever length and width) across the X axis until the right most edge of the rectangle and this iteration needs to happen over the Y-axis (not sure if I explained clearly enough .  So now we have rectangular tiles laid out across the bounding rectangle for the polygon. GDI+ gives us a clip method that allows us to clip the rendering surface to a specific graphics path or region. Using the clip method, clip the drawing surface to be the graphics path for just the Polygon so that only tiles within the polygon's graphics path get rendered on the screen. We could apply other transformations to the rendered tiles like offseting, rotation or a gap between each tile.

Coming up with the most efficient way to count the number of tiles (including partial tiles) was a little trickier than rendering the tiles.  It turned out that the ideal approach was to essentially count each tile as it was drawn and checking whether the tile was partially or fully part of the polygon's graphics path/region. So, there is this method Region.IsVisible that lets you test whether a rectangle is partially or fully contained within a graphics region. During the rendering of each rectangular tile, the method was used to check whether the tile was going to be part of the region associated with the polygon and was counted if it was going to be. Even though, this was the most efficient solution for the problem, we did nt see 100% accuracy sometimes when rotation transformation was applied to the tiles. Still havent found an answer to this anomaly.

Related posts:

1. Eyespot – AJAX App for Video Editing
2. LINQ to My Domain
3. How to REALLY do Page Preview in Java with Embedded HTML Rendering

photo credit: bark

We've discussed the benefits of Agile development before and that the iterative approach to building the architecture -- where you explore architectural issues (very few apps are completely new and unknown) a little bit through each iteration -- is an effective method for arriving at a good application architecture. What is less obvious is the psychological benefit to working in this way.

It's frankly been a while since I've participated in a large waterfall project directly (one benefit of working for a firm that does agile software product development), but I regularly talk with folks who are still in the corporate trenches doing things the old fashioned way. One thing that hasn't changed is the BIG ARCHITECTURE wrestling match up front. Management wants to know the architecture, the guys with "architect" in their job titles want to know the architecture (so they can criticize, natch), the project manager(s) want to know the architecture. How will we scale? How will we ensure security? More useless brainpower is spent on this ultimately fruitless task -- solving problems that end up being no problem at all -- than almost any other activity in the project.

What mostly isn't recognized by participants and observers is the psychological burden this puts on the development teach. Making big decisions early, often in the absence of critical information, produces a lot of anxiety. This often leads to poor decision making and procrastination (where necessary decisions are pushed back to a later date).

Agile, in contrast, provides a natural divide and conquer approach to breaking big tasks into smaller tasks and allows the development team to make decisions at the right time with the right information. I'm halfway convinced that all of those "enterprise architects" at big firms are really just stress counselors for tech leads suffering from waterfall anxiety.

Related posts:

1. Agile Development Improves ROI – But RFP Processes are Stuck in Waterfall.
2. Under the Waterfall: The Cost of Bugs After Launch
3. IA and agility

However, testing Sphinx code is not easy at first. Since Sphinx works by leverging database commit hooks, it cannot be tested within the bounds of unit testing framework that rails provides. This is understandable because, in rails testing, a transaction is started before each test that is bound to rollback after the test is finished. Since the test data is never committed, sphinx doesn't get a chance to index anything and cannot be tested.

The documentation for sphinx testing suggests using cucumber for integration testing. To me, cucumber test are still miles away from the smallest piece of sphinx code (inside Model) to be tested. So, I turned to how transactional code is tested in rails framework for some cue.

Here is what I ended up with:

 
class TransactionalUserTest < ActiveSupport::TestCase
  // any transactional test needs to have this
  self.use_transactional_fixtures = false
 
  context "with no users in database" do
    setup do
      // clear the existing data for our test - not sure if this affects other test but we use machinist instead of fixture files, so we should be good here.
      User.destroy_all
      UserProfile.destroy_all
    end
 
    context "with a few users created" do
      setup do
        @john = @david = nil
        // any data for sphinx test should be wrapped in transaction so sphinx can see these changes
        User.transaction do
          @john = User.make(:first_name => "John")
          @david = User.make(:first_name => "David")
        end
      end
      should "find user with first name john" do
        // start sphinx server
        ThinkingSphinx::Test.run do
          // give sphinx an opportunity to index newly added data (required before calling search)
          ThinkingSphinx::Test.index
          assert_equal([@john], User.search("john").collect)
          assert_equal([@david], User.search("david").collect)
          assert_equal([],User.search("cheese").collect)
        end
      end
    end
  end
end
 

Isn't it nicer to be able to test sphinx code in isolation

Related posts:

1. Testing various roles in ruby on rails
2. Agile Development and Testing: Unit or Montecarlo?
3. Unit Testing: Can You Afford Not To?

photo credit: B Rosen

I remember my first real grownup and serious web project outside of the university environment. It was 1994 and SSL was a novelty. People were making insane predictions that one day up to $600 million (think Dr. Evil) worth of consumer goods would be sold on the web worldwide. In 2007, just Canadian B2C sales were US$12.9 Billion.

Some folks, especially startups and smaller companies, saw the web as an opportunity to shake up the established order and establish a new sales channel or an entirely new business model. They invested what they could in building the first of what became known as e-commerce sites. Among established players, and some more conservative smaller players, there was initial hostility toward the new medium. When in 1994 I proposed to Ameritech (now part of SBC/AT&T) that they bring their lucrative print yellowpages online, I was run out of Hoffman Estates on a rail.

The con arguments ran as follows:

1. Investing in the web will increase our IT costs and require us to support lots of new and different technologies.
2. It will spoil our existing business model.
3. The platform is unproven. We have a proven client/server (desktop, etc., etc.) solution which is far better than some primitive web site.

These were all valid points. And if the web was just the idea of some crazed developer, then it could have been safely ignored.

But the web was being rapidly adopted by both consumers and businesses, knocking down barriers to entry wherever it went. The network effect was about to slap the entrenched players upside the head.

Now we're seeing much the same thing in the world of mobile, which right now means mostly iPhone but will at some point include more players such as Android and perhaps Blackberry devices. The same objections are being raised towards the iPhone -- more IT costs, spoils our business, unproven/not capable -- and the answer is still the same: if you ignore iPhone/mobile, then the network effect is going to knock you upside the head.

Related posts:

1. Ajax and Browsers: Recapitulating the Early Days of Personal Computers
2. Will Q4 iPhone Sales Surpass Expectations?
3. Apple’s Earnings Call: Enterprise iPhone Adoption Growth

photo credit: musiciennedusilence

A friend of mine from college is a physics professor who does a lot of stuff with the space station and the new Google Lunar X Prize, that awards up to $30 million for the first non-governmental organization to land a robot on the moon. He likes to get his students involved and has a gift for expressing things in terms they can immediately grasp. "The robot," he tells them, "can be small. Think of an iPhone with wheels."

When something has penetrated the collective consciousness the way the iPhone has, it changes the way we look at what is possible.

Related posts:

1. jQuery vs. Prototype: OO JavaScript with or without training wheels
2. “Developing iPhone applications using Ruby on Rails and Eclipse, Part 2: Displaying iPhone content to the client” Also up on IBM Developerworks
3. iPhone SDK: UIViewController Testing & TDD

photo credit: suki_fotografiert

A while back I looked at the Vaadin Plugin and tried to make it work with the Multiton PureMVC. Back then I proposed the following code:

 
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;
 }
 

A little more noodling and you'll see that doesn't work. In a multi-session environment, each user will need his own core. Furthermore, inactive cores should be harvested, otherwise we will have a memory leak.

A little repair work and we have the following code, which does half the job:

 
public static ApplicationFacade getInstance(HttpSession session) {
   String id = session.getId();
   if (instance == null) {
     // nuke the multiton so we can do the grails recompile
     if (ApplicationFacade.hasCore(CORE + "_" + id)) {
       ApplicationFacade.removeCore(CORE + "_" + id));
     }
     instance = new ApplicationFacade(CORE + "_" + id));
   }
   return instance;
 }
 

We get the session through the Vaadin ApplicationContext object. So, now we get a fresh core per session. But we still have the problem of leaking memory every time a session or Vaadin application is invalidated. Neither PureMVC nor Vaadin have any lifecycle methods to hook into for cleanup. In PureMVC that is understandable, since it isn't really designed for a web application context, but this seems a more serious oversight in Vaadin.

We can hook some PureMVC cleanup by storing the key as a session attribute and using a HttpSessionListener to clean it up. I'll test that out and blog about it in the future.

Related posts:

1. Making Vaadin, PureMVC and Grails Work Together
2. Notification Testing with PureMVC and FlexUnit
3. Griffon and a PureMVC Plugin: Some Initial Thoughts

Over 90% of iPhone apps are approved within 14 days of submission.

Given over 100,000 apps in the store from a wide variety of developers (from amateurs to experts) and a wide variety of topics, that's actually pretty good. Apple claims that most rejections are actually for bugs in code, which makes sense given the wide disparity in development quality and test coverage.*

* For example, are you testing your software for ipod touch as well? You should - applications have been rejected for working on the iPhone, but not the iPod touch.

Related posts:

1. Apple’s Earnings Call: Enterprise iPhone Adoption Growth
2. Will Q4 iPhone Sales Surpass Expectations?
3. 8 Tips & Tricks When Starting Objective-C iPhone Apps: [self.paradigm shiftFrom:@"ruby" to:@"objective-c"];

photo credit: Hugo90

This morning I sat through two pitches by two startups looking for funding. I won't get into the details, but they both had clever ideas at their root. But while one company was attractive and poised for success, the other was mediocre and not getting much traction. Why was that? They both had clever ideas, no?

Over the years I've looked at a lot of business plans for Venture Funds. The first lesson that I learned was that cool ideas didn't equal successful companies. While I would get all hot and bothered by a particularly elegant software solution, the VC's I was consulting to preferred the plans that understood the market and the customers in it (and had a kick ass management team, natch).

The "good" company from this morning had a clever idea that was a clear solution to a customer problem. The mediocre company had a clever idea that didn't really solve a specific customer problem.  What accounted for this difference? Well, the "good" company spun out of a larger business, while the mediocre came out of a government funded not-for-profit.

The easy conclusion here is that business folks have the discipline of competition working for them, while NFP's don't. It's true that I've seen companies that have no valid competitors flounder when it comes to a business plan, but that's a disease that's not restricted the the NFP realm.

No, instead this seemed to be a different ivory tower problem: lack of a customer. As a result their product definition was crap. Who would want this thing? Always start with the customer.

If your startup idea includes a software component, you should make sure that your software development practice also keeps the customer front and center. It may be tempting to start with architecture, to see if your software solution can "scale." But if you get the customer wrong, you won't need to scale.

That why with most software products that we develop, we start with user modeling. We do move on, eventually, to data modeling, process modeling, etc., etc., etc., but only after we've set the tone, so to speak, with user modeling -- personas, user stories, task flows, etc. Everything that follows is then motivated by the customer.

So, before you spend a million dollars on that cool idea, validate it with some customers to see if they actually want it.

Related posts:

1. Upcoming Talk at RIApalooza: Fast. Smart. Agile. User Experience Driven Agile Development
2. Web 2.0 Expo: Behavior-Driven Development with Rails and RSpec
3. Gmail, agile development and user experience design

photo credit: NIOSH

Academic research is incredibly inefficient when it comes to producing products and services. Grad students, post-docs and professors work on "problems" that some collection of graybeards has deemed "interesting." Their "solutions" -- sometimes successful, sometimes not -- are published as research and then, occasionally, if the stars align, is turned into a product or service through the application of venture capital via a startup.

The only thing less efficient in producing innovative products and service is the corporate R&D department. In most places you have a phase-gate process (waterfall under a different name) of conceptualization, feasibility testing, definition/specification, development and launch. They are typically bloated, bureaucratic monstrosities with huge documentation requirements and endless committee meetings that do more to stifle innovation than promote it.

There is a way, however, of applying Agile principles to the concept phase, and it relies on two of the basic tennets of Agile: failing fast and self organizing teams.

Failing Fast

Fast also means cheap (time is money, etc.). If with the expenditure of $1,000 and three days I can tell you with 50% certainty that a particular idea is any good, or I can spend $50,000 and 3 weeks and tell you with a 80% certainty whether a particular idea is any good, which process would you prefer? If your budget for developing new ideas is $250,000, then you'll be able to test 5 ideas in the $50,000 case, and 250 ideas in the $1,000 case.

If you have a low yield on your ideas, i.e. few of them look good after vetting, then two things happen. First, you're really rolling the dice on coming up with a decent idea for taking the next step into feasibility testing. Second, since so much is riding on a few decisions, the organization "clenches" and pressurizes the decision making process. That's not a good recipe for wise decision making.

Self Organizing Teams

If you practice top-down management throughout your business, you are going to create a class of passive, dependent employees. It would not occur to them to come up with business and product ideas for your business. Funny thing, though, any 1000 employees, properly motivated and harnessed are smarter than any single CEO.

The key to unlocking this potential is empowering these employees to take initiative. We think self organizing teams -- teams that are given the responsibility and authority to organize and manage their own work as a unit rather than receiving it from a manager -- are an excellent way to empower your workforce. Another way to put this is "give them problems, let them come up with the solution." Implement this management pattern throughout your organization, and you have the beginnings of that creative workforce that can help you innovate.

Publish Problems, Welcome Solutions

There is room for experts in all of this: have them define the key problems that your organization faces. We need a way to reduce our shipping costs. We need a way to prevent our customers from switching to cheaper offshore competitors. We need a way to leverage new wireless technologies in our products. Publish these problems to your company (in itself a very useful business excercise) and welcome proposed solutions from all employees. Reward your employees for their suggestions. Reward them and involve them when their ideas make it past the Concept Phase.

Again, your experts can weigh in at this point in selecting the winners among the proposed solutions. We'll get to how to do quick and agile feasibility testing in an upcoming article.

Related posts:

1. Agile Development for Product Managers: Why Agile Testing Rocks
2. Scenarios in Product and Project Management
3. Your SDLC or Your Product – You Decide

As January 26th, the rumored date for Apple's rumored tablet unveiling draws near, the hype and anti-hype keeps getting more and more over the top:

Five Ways Apple's Tablet May Change the World

The world doesn't need an Apple tablet, or any other

and the inevitable

3 Reasons A Microsoft-HP Tablet PC Would Trump Apple

If you want to keep up to date on the rumors, Gizmodo has a regularly updated run-down here.

There are a couple of places that have more informed speculation and insightful commentary - I'd recommend these three in particular:

Antacid Tablet by ars technica's John Siracusa:

... There's also the popular notion that Apple has to do something entirely new or totally amazing in order for the tablet to succeed. After all, tablets have been tried before, with dismal results. It seems absurd to some people that Apple can succeed simply by using existing technologies and software techniques in the right combination. And yet that's exactly what Apple has done with all of its most recent hit products—and what I predict Apple will do with the tablet. ...

So how will an Apple tablet distinguish itself without any headline technological marvels? It'll do so by leveraging all of Apple's strategic strengths. Now you're expecting me to say something about tight hardware/software integration, user experience, or "design," but I'm talking about even more obvious factors:

• Customers - Apple has over 100 million credit-card-bearing customer accounts thanks to the success of iTunes.
• Developers - Over 125,000 developers have put over 100,000 iPhone OS applications up for sale on the App Store. Then there are the Mac OS X developers (though of course there's some overlap). Apple's got developers ready and able to come at the tablet from both directions.
• Relationships - Apple has lucrative and successful relationships with the most important content owners in the music and movie businesses.

These are Apple's most important assets when it comes to the tablet, and you can bet your bottom dollar that Apple will lean heavily on them. This, combined with Apple's traditional strength in design and user experience, is what will distinguish Apple's tablet in the market. It will provide an easy way for people to find, purchase, and consume all kinds of media and applications right from the device. It's that simple.

Thoughts on what an Apple tablet should be – or not by Andy Ihnatko

Apple always asks themselves simple and stupid questions like “How will this device be used?” and “Will this be used by human beings with, I mean, arms and hands and fingers?” and stuff like that.

The iPhone UI isn’t a desktop user interface where a pen takes the place of a mouse ... which is the model that previous smartphones followed. It was designed to be held in one hand and tapped with your thumb. Occasionally you’d use the index finger of the right hand to key things in.

You want to try to figure out the UI of the RAT? Go get yourself a comic book, or any other rectangle that measures roughly 10” on the diagonal. Hold it as though you’re reading what’s on the surface.

You see the problem? Your fingers get in the way. Think about how big that surface is, too. That’s a lot of acreage to scan, looking for the right buttons to push.

While you’ve got it in your hands, imagine that it’s a sheet of thin steel. That’s heavy, isn’t it? Hard to hold up for long periods of time.

Think about how a user interface would have to incorporate those observations. Now imagine that you’ve been doing this experiment for four years and not four minutes.

That’s a very long list of observations. If you didn’t come up with a workable solution, don’t worry: I think Apple has.

and

The Tablet by Daring Fireball's John Gruber.

... The way Apple made one device [the iPhone] that did a credible job of all these widely-varying features was by making it a general-purpose computer with minimal specificity in the hardware and maximal specificity in the software. And, now, through the App Store and third-party developers, it does much more: serving as everything from a game player to a medical device.

Do I think The Tablet is an e-reader? A video player? A web browser? A document viewer? It’s not a matter of or but rather and. I say it is all of these things. It’s a computer.

And so in answer to my central question, regarding why buy The Tablet if you already have an iPhone and a MacBook, my best guess is that ultimately, The Tablet is something you’ll buy instead of a MacBook.

Gruber's a bit more gung ho than Ihnatko or Siracusa, but they both make a pretty compelling case that something very interesting is about to happen over the next year.

Related posts:

1. iPad: Instant Reaction to Apple’s Tablet Event
2. iPad: How big is the space between laptops and iPhones?
3. Where the iPad will take over: 15 examples

Once you have sufficient experience managing projects with Agile practices you should feel comfortable adapting those practices to your own teams and projects. As long as you are still following Agile principals this is okay. In general, this is what’s going on in smaller companies. Having coached a number of large organizations transitioning to Agile I can say this isn’t how they look at things. The problems start when you adapt the practices, but try to deliver all projects in an identical manner. This makes sense for waterfall-like delivery methods. But, when an organization comes up with its own version of “Agile” it can only work for the subset of projects it is tested on. Rolling this out to the entire organization as “the way” to deliver projects from them on is a failure pattern. The principals are lost and so is the adaptability of the organization. The time spent to move over to agile is immediately wasted.

Photo Credit:
kevindooley
under a Creative Commons Attribution License

Related posts:

1. Agile 2009: A reminder of why each team needs leadership
2. Building a High Performance Agile Team: Assume You Will Be a One Hit Wonder
3. Effective vs Efficient Teams