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

This year's Day of Mobile had a number of interesting tracks, including the ever popular hack-a-thon.

In the hack-a-thon, developers worked alone or in teams to build applications that targeted any one of the mobile platforms (iPhone, Blackberry, Android, Palm, Windows Phone) and presented their applications to the attendees to win prizes.

Our own Mike Laurence, who won the in in the open source category for developing an iPhone application for the Lighthouse issue tracking service. In three hours.

How? By using our recently released Core Resource Framework, a local/remote resource management framework that accelerates the creation of API clients, our soon to be released DynamicCell project, and integrating with the Lighthouse API. Pretty sweet.

I talked to Mike about it afterwards, and here's what he had to say:

"Three hours is a pretty short time to develop an application, but this was a good chance to test out the Core Resource framework. I've been working on the framework itself for the last five months or so; for the hackathon I decided to see if I could actually make a working app in 3 hours. I ended up creating a Lighthouse account (bug tracking website) for the project, and because Lighthouse has a nice API, that's what I used as my source. I did get an app up and running in 3 hours, which was pretty exciting. It even looked decent, due to the other open source project I announced (DynamicCell.")

The Core Resources framework is available now, and look for an announcement on the DynamicCell project in the next week or so.

We're building a fair number of iPhone and iPad applications now, and it's great so have someone like Mike on the team and contributing back to the community.

Related posts:

1. 6 GWT Resources for the iPhone
2. Rails Development for iPhone with rails_iui
3. “Developing iPhone applications using Ruby on Rails and Eclipse, Part 2: Displaying iPhone content to the client” Also up on IBM Developerworks

The midVentures25 event is happening this Thursday, and Pathfinder is proud to be sponsoring the event.

midVentures25 is the first Chicago-based startup demo day & conference: 25 of the best investor-ready early-stage startups will demo their products in an open-floor expo.

The top 5 startups will have a chance to pitch to an audience of entrepreneurs, VCs, angels, bloggers, media and Chicago's tech community. A panel of expert advisors will ask the tough questions -- ultimately choosing one company to win over $10,000 in services.

The focus of midVentures25 is to show the national technology and investment community that the Midwest has an abundance of early-stage innovators within the technology, consumer, and sustainability space. You can expect to engage thought leaders in education, art, media, business, science, and technology during the conference.

There are a lot of great innovations that continue to come from the Chicago community, as we know from the early stage clients we've helped towards success. We're looking forward to an event like this that brings the people that make this happen together. It should be a great evening.

Related posts:

1. Pathfinder sponsoring Day of Mobile in Chicago
2. Upcoming Pathfinder Appearances
3. Why Chicago is Rails-town, USA

This should be a very cool event , and we're excited about interacting with other mobile developers in the Chicago area. We look forward to seeing you there!

Day of Mobile is an all day event for mobile developers and enthusiasts that will take place at IIT on March 6, 2010. The overall goal of the event is to better prepare both Chicago's application development community and companies with mobile initiatives for the upcoming mobile revolution. We will cover a myriad of different topics relative to mobile development and strategy such as platform SDKs, cross platform development, multimedia, CMS/SMS, mobile business models and many more. The event will begin with a breakfast at 8AM and conclude after a keynote speech and hackathon awards ceremony at 4PM. Throughout the day, there will be talks running concurrently with one another in two adjoining ballrooms.

Related posts:

1. Pathfinder sponsors the midVentures25
2. Why Chicago is Rails-town, USA
3. Q&A with Trace Johnson of Chicago-based mobile-payment start-up Mpayy

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

Instead of a "loading" animation that we may bail out on, why not tell a story? I was impressed with this technique used by BMW.  They are running banner ads on NBC's site which hypes the upcoming Olympic events. You see a car in the banner ad, you expect to click and see more car. But you don't. Instead, a blank white screen with just a few short words pops up. But the words tell a quick paced story. phrase by phrase, of what joy is. Joy is Timeless. Joy is Freedom. Joy is Innovation. And below those words is the "loading" indicator. 10%, 20%, 32%, and so on. A nice example of storytelling used in design - if you are going to make someone wait (or have to, because you are loading a high-end car video), consider getting them engaged with a story.

http://www.bmw.com/com/en/insights/technology/joy/bmw_joy.html

Related posts:

1. Ajax and Design
2. Art vs. Design, the Art of Design, or the Design of Art
3. Design Doesn’t Just Mean Color

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

1. The daily commute. It's a simple matter of ergonomics here. I will use the iPad, sold with a cheap data plan when I'm sitting down on the El, rather than the iphone. Because it has a bigger screen, and it's already connected. I won't use my laptop, because it doesn't come with a data plan (or only an expensive one that I won't buy), and it's pretty uncomfortable to use in a cramped row of seats. I'll use it instead of a laptop because the form factor works much better, and because I will have bought the data plan bundled with the iPad.

2. The eBook reader. I'll use it instead of a Kindle because it will be good enough (or better), and I can do a lot more than read with it. My guess is there will be more people that read on the tablet than who buy a dedicated reader. (Just as there are more people who do photo sharing on facebook than on flickr.)

3. In the Kitchen. If I'm in a situation where a sealed, mess resistant device with a big screen is a big advantage (like a kitchen) then I will use the tablet. I will prefer it to the iPhone because it's bigger and I can look at it while I'm doing something else, and I will prefer it to a laptop because the keyboard will not get gunked up. There are already devices retailing around $300 to store and retrieve your recipes in the kitchen - an iPad with the right recipe app will run rings around that.

4. Video calls on the go. If it's always on, like an iphone, and it has video (like my skype video phone) with a front facing camera, then I will replace my skype video phone with it, and I'll make more video calls. This isn't in v1, but you can bet that it will be soon, and when it is, it'll be a killer app for the iPad.

5. In the store. Walking around, showing people more information, more details. The form factor is better than a laptop, and the screen is better than an iPhone. Which would you chose in that situation?

6. On a trade show floor. Very similar to the store situation.

7. Any other place where you would say "hey, let me show you this!" It's cumbersome with a laptop. You have to say - hey, come here, look at this...

8. In the restaurant. I could see it used in a restaurant, taking orders, or at the reservation desk.

9. For doctor making rounds. In multiple hospitals (as many do.) A doctor or nurse making their rounds is a similar situation - they'll use their iphone when nothing else is available, but they'll prefer the tablet when it's available, because of the larger viewing surface. They'll prefer it to a laptop most of the time because of the true portability.

10. Online games. There's a reason games have been a big hit on the iPhone - like the wii, it's a different gaming platform than a gameboy, and unlike a laptop, it's truly portable. Add a bigger screen and a faster processor, and you've got a killer gaming platform.

11. Social games. A special case of #10: Playing chess or another game on a table with a friend or friends (or against the computer.) One of the issues with sharing a laptop for gaming is that you can't really do face to face. You're both looking at the screen, not at each other. A tablet can be laid down between you and used as a gaming console.

12. Online courses and test preparation. You're doing a lot of reading, and watching a lot of video, and probably answering mostly simple multiple choice questions, rather than writing essays. You can do it on the go, or sitting down at a table. A tablet could be a much more enjoyable way of doing this than a desktop or laptop.

13. Watching movies. You don't watch movies sitting at a desk - you do it lounging, on a couch, in an armchair, or on the bed. If you're not watching it on a big screen, this is the way to do it. On the train, in the plane, in the back seat of the car, on the couch, on the family room floor.

14. On the job site. Contractors and architects do a lot of site inspections/checklists in the field where an ipad would be great – my guess there are a lot of other applications for them as well. Just as in a medical situation, concerns about durability can be addressed through functional cases.

15. Turn by turn navigation in the car. The bigger screen is a natural for this. A purpose built case with gps is probably not that far behind.

Got any other situations that the iPad is suited for? We'd love to hear about them.

Related posts:

1. iPad: Instant Reaction to Apple’s Tablet Event
2. iPad: How big is the space between laptops and iPhones?
3. Why would you use a tablet instead of a laptop? (In Pictures)

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

It's no accident that Steve Jobs is arguably the ultimate technology pitch-man. He's worked with some of the best designers, ad agencies and creative people on the planet even since the early days of Apple. But how would he pitch your idea? It's a fun question to ask and I found a book that just might have the answer. While browsing in a discount brick-and-mortar bookstore I came across "The Presentation Secrets of Steve Jobs" by Carmine Gallo of Businessweek.com.  There was one copy on the shelf and it immediately caught my attention. As I flipped through the pages, I was impressed with the many "how-to" pieces of wisdom. For example, you'll see how answering four simple questions can yield a powerful elevator speech. You'll see how to use high impact words, tight headlines and key numbers to get your point across in a way that seems effortless. While I think the book is a "must have on your desk" for product managers and marketers, I also think it's a great reference for designers to think about what makes a design more marketable and enticing to the customer.

Related posts:

1. Salaries Go Up for Ajax Jobs
2. Scenarios in Product and Project Management
3. Reconciling the Powers of Less and More in Product Design