Category: Software Development

Teamicide

Perry Hertler, Monday, March 15, 2010 @ 7:44 pm

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!

Software Development Software Development

Who values your product and do you value them?

Michael Walkden, Friday, March 12, 2010 @ 11:26 am

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?

Topics: , , , , ,

Software Development Software Development

Optimizing has_role? in acl9

Sharad Jain, Wednesday, March 10, 2010 @ 10:11 pm

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.

Software Development Software Development

Refactoring versus Rewriting

Dietrich Kappe, Monday, March 1, 2010 @ 5:09 am

Refactoring versus Rewriting
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 borne out of a misunderstanding of Agile development, but 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, you don't have to do expensive rewrites. Of course anyone who has ever maintained code knows that this isn't 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.
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), 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 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.

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.

Continue reading »

Topics: , ,

Software Development Software Development

Remembered: Claude Shannon

Dietrich Kappe, Wednesday, February 24, 2010 @ 12:38 pm

Claude Shannon

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.

Topics:

Software Development Software Development

mort_calc gem: Rails Mortgage Calculation Gem

Perry Hertler, Tuesday, February 16, 2010 @ 3:26 pm

I recently published the mort_calc gem at gemcutter.org. The code can be found at http://github.com/perry3819/mort_calc/.

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

Calculating the monthly payment is straight forward.

monthly_payment

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.
Continue reading »

Topics: ,

Software Development Software Development

Post-Agile in the Game Development World?

Dietrich Kappe, Monday, February 15, 2010 @ 4:52 am

V&A Kanban December 7
Creative Commons License 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. Continue reading »

Topics: ,

Software Development Software Development

Why Computers are (aren’t) Better Than People at Playing Chess

Dietrich Kappe, Friday, February 12, 2010 @ 9:54 pm

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.

Continue reading »

Topics:

Software Development Software Development

Single Purpose Devices vs. Flexible Platforms and Functional Cases

Bernhard Kappe, Tuesday, February 9, 2010 @ 6:54 am

A few weeks ago, I wrote about the Skype Video Phone, part of a trend towards trading needless complexity for simplicity and ease of use. It's also on the wrong side of another trend: The trend away from single purpose mobile devices to flexible mobile platforms.

smdemyrecipe

panasonic-mca-h1-nursescanning

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.
Continue reading »

Topics: , , , , , ,

Software Development Software Development

Tiling a 2-D Polygon using C# GDI+

Karthik Muthupalaniappan, Monday, February 8, 2010 @ 4:14 pm

Tiling a Polygon

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.
Continue reading »

Topics: , , , ,

Software Development Software Development

Architectural Anxiety and the Waterfall Approach

Dietrich Kappe, Monday, February 8, 2010 @ 4:50 am

an unwitting victim...bwahahhahahaa
Creative Commons License 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.

Continue reading »

Topics: , , ,

Software Development Software Development

Unit Testing Sphinx

Sharad Jain, Saturday, February 6, 2010 @ 7:28 pm

Sphinx (and its rails plugin thinking-sphinx) is my choice of search engine on ruby/rails project. It is powerful yet super easy to setup.

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 :-)

Software Development Software Development

Flashback: The iPhone and the Early Days of the Web

Dietrich Kappe, Friday, February 5, 2010 @ 3:19 pm

269/365 - why even have that deal?
Creative Commons License 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.

Continue reading »

Topics: ,

Software Development Software Development

To the Moon: an iPhone with Wheels

Dietrich Kappe, Friday, February 5, 2010 @ 2:42 pm

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.

Topics: ,

Software Development Software Development

A Slight Correction to using PureMVC with Vaadin

Dietrich Kappe, Monday, February 1, 2010 @ 2:32 pm

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.
Continue reading »

Topics: , ,

Software Development Software Development

Launch: Pathfinder Newsletter

    Get a monthly update on best practices for delivering successful software.

    Subscribe via email


    Subscribe via RSS      RSS icon

Categories

Topics

Blogroll

Search

WordPress

Comments about this site: info@pathf.com