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

• The iPhone is ranked #1 in customer satisfaction in J.D. Powers' survey.
• Corporate clients have doubled.
• 70% of Fortune 100 are actively piloting or deploying iPhone. About 50% of FT 100 are doing the same.

Not bad given that Apple has only been in this business for 2.5 years.

This certainly jibes with a lot of what we are seeing from our customers, that the iPhone is the first choice for mobile application development and the first choice among consumers and corporate customers when given a chance. It also validates our recommendations from last year on which mobile platform to develop for.

Let's see what tomorrow's big announcement brings.

Related posts:

1. Apple Earnings Call: 90% of iPhone Apps Approved within 2 Weeks
2. Will Q4 iPhone Sales Surpass Expectations?
3. Betting Your Business on the iPhone

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

If you walk away with one concept after reading this book it should be to believe that success comes from people. The best companies focus on developing problem solving skills and local decision making. These companies favor adaptability over efficiency.  These companies make money to survive rather than simply surviving to make money.

The book starts out by defining the concept of frames, “the unspoken mental constructs that shape our perspectives and control our behavior in ways we rarely notice.”  A useful way to look at software development. I was happy to see their description of Agile as evolutionary rather than revolutionary. This is why when you explain the set of Agile practices to those with extensive experience they usually nod their heads and say they are already doing them. I have been telling people that Agile is a collection of best practices that good software shops have been using for years. Now I have a reference to support this.

Software craftsmen should read chapter 2 about technical excellence. The chapter goes through each engineering practices, explains it such that a non-practitioner can understand and gives examples. After they are done they should make their manager’s read it, then their managers.

Conclusion

I wish this book had been written 5 years ago. It would have saved me considerable effort and time trying to define what a well run software organization looks like. Your mileage my vary, but I will say that I intend to keep this on my bookshelf right next to Managing The Professional Service Firm.

Related posts:

1. Software Development and Wasted Motion
2. What’s the value of Agile out of the box?
3. Agile 2009: A reminder of why each team needs leadership

photo credit: LKaestner

Back in college I used to work at the main campus computer center. That was back in the days of time sharing Unix and mainframe computers, so it was a great way to get some extra CPU time for my various projects. Besides locking up at closing time (I loved to work the 10pm-3am shift), I had to change toner cartridges, support the brick macs, windows 3.1 machines, and the various Unix and Mainframe terminal users.

Over time, you learned to identify various user types. The vast majority of users had simple "hey, how do I do this" or "this ain't working" types of issues. Of the rest there were two main problem user types: the "helpless bunny" and the "walking crisis."

The Bunny displayed profound helplessness in order to get you to do their work for them. The first time I had a Bunny, I was caught unawares and spent the better part of my shift formatting their document in Wordperfect. With subsequent Bunnies, I used tough love and gave them manuals and man pages to read.

The Walking Crisis was typified by the grad student who waited until the last moment to add end notes to their masters dissertation, and dammit, if they were going to suffer, you were going to suffer. Their technique was to try to convince you that their problem was your problem, i.e. the fact that they couldn't do two months of work in five hours was a shortcoming of the software, and thus a support issue.

The more enthusiastic you were about helping users, the more susceptible you were of being dragged down by the Bunny and the Crisis.

Professional Software Development

When I left school for the big time of professional software development, I quickly found the Walking Crisis existed there too. When these problem types were in position of influence or even the project stakeholder, then they didn't just make the life of one person miserable, they could whipsaw and demoralize an entire team. And while they were poison to a team, by themselves they were capable of pulling heroic all-nighters to make up for their lack of discipline. This perceived capacity for hard work (minus the self-inflicted need for it), often puts the Walking Crisis into positions of power.

It was around this time that I became a fan of professional project managers. If you were lucky enough to get one of these rare beasts on one of your projects, you at least had a chance of surviving. If the Walking Crisis procrastinated decisions, a good project manager could ring the alarm bells in advance of any software death march.

Agile is not Undisciplined

When I began to embrace the joys of Agile Software Development, the Walking Crisis made a strong comeback. Since Agile software development methods embrace change, the Crisis can delay all the hard decisions and work until the last few iterations and slip them in as some basic change.

Of course the same things could happen in a more traditional waterfall model of software development, but somehow lots of folks have the idea that Agile is just fast and loose and undisciplined. Nothing could be further from the truth. In Agile you grapple early and often with schedule and scope. From the second or third iteration you are dancing with velocity and the backlog, making decisions on what is in or out.

Be Careful in Choosing Your Product Manager

If your organization is developing software, you may be in the position to choose the product manager or software development liaison. Pick someone you already know works well with teams and has a good grasp of your business and the marketplace. Be careful that you don't mistake their heroic "Walking Crisis" efforts for competence, else you may be condemning your software product to failure.

Related posts:

1. Agile Development for Product Managers: Why Agile Testing Rocks
2. Agile 2009: A reminder of why each team needs leadership
3. Agile Software Development and the Lazy Client Trap

photo credit: °Florian

Yes, Cloud Foundry has been acquired by Spring Source and seems to be morphing into a for-pay service, and there hasn't been a new build packaged on the Cloud Tools project page since January of 2009, but if you dig in the SVN repo, you see there's a bit of activity. Before I try building from source, I wanted to see how hard it would be to get 0.6 Grails plugin working with a Grails 1.1.1 app.

Well, harder than I thought. There's a real lack of documentation around cloudtools for one, and the radio silence on the project page over the last few months hasn't helped. Fortunately, Don over at AlterThought has put together a nice post that covers most of the pitfalls and problems with the CloudTools Grails Plugin. A few things they don't address and I thought I'd throw in here:

1. The CloudTools scripts expect the plugin to be located in the Grails project directory.

That isn't the case anymore. The plugins have moved to ~/.grails/1.1.1/projects/<your-project-name>/plugins/. The one script that barfs on this is ~/.grails/1.1.1/projects/<your-project-name>/plugins/cloud-tools-0.6/scripts/CloudToolsDeploy.groovy which tries to determine the plugin dir through a process that just won't work anymore. Edit the file and replace all the pluginHome cruft with a single line:

pluginHome = "${cloudToolsPluginDir}"
 

That's it.

2. The CloudTools deployment ignores your production configuration and just deploys development.

If your development data source is configured to create-drop, you'll be very disappointed that your database is constantly getting nuked. So, ignore the production environment and just use development! (This will need to be fixed, of course.)

3. When deploying, you need to have a local db running with the same login info/credentials as your production.

What a huge pain. I only discovered this after shutting down my local development mysql instance. Not so good for automated build and deploy. Again, needs to be fixed.

4. Using EBS is pretty dead simple.

Using EBS to persist mysql tables is rather trivial. Just tack on a withNewEbsVolume method call the first time through, then a withExistingEbsVolume, some the first time:

clusterSpec = new ClusterSpec()
                .tomcats(1)
                .topology("SingleInstanceTopology")
                .instanceType(EC2InstanceType.SMALL)
                .slaves(0)
                .withNewEbsVolume(20, "/dev/sdq")
 

CloudTools will create a volume, format it and mount it, populate the db tables to it. Next you find the volume id with something like ElasticFox and edit your config file to look like this:

clusterSpec = new ClusterSpec()
                .tomcats(1)
                .topology("SingleInstanceTopology")
                .instanceType(EC2InstanceType.SMALL)
                .slaves(0)
                .withExistingEbsVolume("vol-1234", "/dev/sdq")
 

Obviously replace vol-1234 with your actual volume id.

OK, that's it. With this configuration, I'm able to get a Grails app up in a matter of minutes with a persistent mysql db.

Next time: building from source.

Related posts:

1. Making Vaadin, PureMVC and Grails Work Together
2. Grails and Google App Engine: Birthing Pains
3. Grails and JSONP: How Easy is That?

photo credit: tallkev

Last weekend I was watching a movie with my kids. In the movie there was a chain of monkeys that needed to pass on the message from one character to one on the other side of the chain. The message went something like, “Don’t throw us over the wall. There must be another way. We will all be killed.” As it went through the chain and the receiver heard, “Throw us over the wall. It’s the only way. Banana.” The scenario seems ridiculous, but its roughly equivalent to how many companies approach software product design. Often times companies don’t realize they are creating a product at all. They think they are just running a project and focus only on delivery of that project as if it is the only artifact of their work.

The problem stems from the fact that when organizations reach a sufficiently large size they must focus on consistency of delivery and efficiently using people’s time. For large organizations this is part of the mix that makes up their competitive advantage. However, the sheer size and number of moving parts required to enable clocklike consistent delivery leads to the most knowledgeable people about the customer never directly speak to the people responsible for building the product. Or translated into a traditional SDLC, the definition/high level design team isn’t communicating with the build team. In my experience they are usually two different groups of people. I’ll give you an example:

A while back, I was leading a software development team creating a product to be used by all 170,000 of my customer’s employees on a daily basis. They happened to have a team of user experience designers and wanted to take on the “big picture” part of the design themselves. This company could afford the best and the brightest talent - and was able to attract them. Individually the folks on this team were talented and knew their craft well. I actually learned a lot just from my brief time with them. However, once we got the design in hand it was obvious that the usability team’s artifacts weren’t going to work for the project. They didn’t meet the end user’s needs nor were they implementable within the time we had available for the project. The client’s design team literately spent months of time showing users lo-fi prototypes, running focus groups, and understanding usage statistics from similar applications. But, the simplicity the end users craved didn’t match the complexity of the business rules required. Upon further investigation the customer’s design team never was given a business level view of the problem to be solved. We tried to merge the business requirements with good usability, but ultimately the franken-design didn’t work. We had to throw out the big picture design and use them as ”guidelines” instead. Clearly it was a waste of talent and a haphazard way to build a product.

In hindsight the design team should have been presented the complex business rules so that their design could incorporate them from the beginning. However, the customer’s SDLC only allowed the design team to be engaged in the definition/high design phase of the project. Once we got to the design phase they were hard to find. By the time we got into the build phase the development team was simply a distraction from other work for these designers. A better model would have kept the designers on the project as each piece is built. I’m not suggesting full dedication to the team – 40 hours a week. That would be nice, but that’s not likely possible in most organizations. I’m suggesting a small time commitment over a long period of time.

Most of the time projects are actually building products. If you are building a product, but focusing SDLC metrics and efficiency, keep in mind that your phases are likely making walls around teams and causing ineffective communication between them. As Matt from 37Signals points out, “Inefficiencies are what make you special.”

Related posts:

1. Design Doesn’t Just Mean Color
2. Tech Terms that Drive Business People Crazy
3. Agile Development for Product Managers: Why Agile Testing Rocks

Dabble->Scribble has a nice blog entry on including log4j logging in Griffon. My favorite part? One of his goals for logging is to "Filter out the cruft from Groovy's massive stacktraces." Amen.

Related posts:

1. Questions About Griffon
2. Griffon and a PureMVC Plugin: Some Initial Thoughts
3. Griffon Plugin Development: Some Nitty Gritty

Never get involved in a land war in Asia.

.

Also, never get involved in a religious war about statically versus dynamically typed languages. Well, maybe just this once.

Periodically, an angry Javascript developer will let loose and flame GWT as a misbegotten spawn of evil. Then all the GWT developers point and chuckle and move on to developing more cool applications. Every so often, though, someone will make a thoughtful comment about GWT, and then we have a fruitful discussion that helps clarify what GWT is and what it does and doesn't do well.

William Shields has either posted such a thoughtful comment or a very high end version of a flame, entitled Lost in Translation or Why GWT Isn’t the Future of Web Development. It is well worth reading, along with Google's Joel's somewhat heated response.

What I want to take issue with is Shields' statement that "Between Javascript, PHP, Python, Perl, Ruby and other languages over the last decade (and yes some have a history going far earlier than that) have clearly demonstrated that indeed the sky hasn’t fallen with loose and dynamic typing."

I'm very much a right tool for the job kind of guy. I love my Groovy and my Ruby, but I also like C# and Java for some things. So, has the sky fallen? I would say yes.

Over the last decade, I've run a software development company that practices agile development. One crucial aspect of our practice is Test Driven Development (TDD). We strive for a high level of code coverage, typically over 85%.  With this approach we deliver software where the number of bugs post-release converges rapidly toward zero, even with enhancements and new features being added.

Now while TDD is great for all software development projects, it is absolutely essential of projects developed with dynamically typed languages. Where statically typed source code without unit tests is like a toxic wasted dump, dynamically typed source code without unit tests is like a nuclear holocaust. Those types of projects just throw off new bugs like a frat house in summer.

Given that many JavaScript and PHP (and Rails, for that matter) projects are developed without unit tests, either because the practice of TDD wasn't common in the organization, or because dynamically typed languages are often the choice of amateurs and, well, "what's a unit test?"

We often take over code developed by other development shops. Sometimes that code has no tests and the client is predictably upset about the bugginess and fragility of the code. I'm usually calm when we take over a statically typed code base, but I'm extremely nervous when the code base is dynamically typed. That's not religious, that's just pragmatic.

Related posts:

1. Josh Bloch Intro Q&A
2. Remain Static or Go Dynamic?
3. Static Typing and the Paranoid Style of Programming

I finally have some small amount of spare time to start working on my Griffon PureMVC plugin. One of the first things to think about is where to we make the marriage between the two frameworks?

Griffon has Models, Views and Controllers, as does PureMVC (actually, it has Commands, Mediators and Proxies, which essentially perform the tasks under MVC). My initial thought is that Griffon's MVC triads really perform the tasks of a complex view, and PureMVC wires these complex views together via it's message bus. So, my thinking is to wrap each MVC triad into a Mediator, with the Mediator mostly talking to the Griffon controller and perhaps the Griffon model.

I'll make some more posts here as my thinking and experimenting evolves.

Related posts:

1. Griffon Plugin Development: Some Nitty Gritty
2. Griffon: Convention over Configuration for the Desktop
3. Questions About Griffon

photo credit: bobistraveling

We have a few simple principles when it comes to software guarantees: either we have developed the software according to our rigorous testing standards or the third party code we being asked to support meets some basic criterea:

1. It has full functional specifications.
2. It has unit tests that provide better than 85% line and branch coverage.
3. It has automated functional tests that exercise 100% of the user stories.

That may seem pretty extreme, but if we're promising to fix bugs on our dime, we can't have it any other way. Doing without these basic criteria is like guaranteeing you can drive from New York to Los Angeles in 30 hours, keeping under the speed limit without a speedometer and without being told what the speed limit is. Spelling it out a little more, if you can't tell me what your application should do, how do I know if it is "broken?" If I can't run and inspect unit tests to tell if individual classes and methods are doing the right thing, how can I quickly tell if my changes have broken the system?

There's lots of damning studies of the software development industry out there, but the NIST study from 2002 is one of my favorites. In it there is a nice little table that shows that in the 1960's and 1970's fully 80% of software development effort was spent on Coding and Unit Testing, another 10% on Integration and System Testing. Only 10% was spent on the whole requirements and design shooting match. Fast forward to the 1990's, when only 30% of effort was spent on what previously consumed 90%.

The story isn't, of course, that programmers became less professional and more sloppy. Rather, people discovered that if you developed the wrong software it didn't really matter how bug free it was. So more effort was spent up front on requirements. In that sense, Agile software development is a little bit of a retro movement since it reasserts the primacy of unit and integration testing, though with Test Driven Development (TDD) and continuous integration you get there in a very different way than before.

Of course most of the 3rd party software we are asked to take over were developed using a waterfall approach. They usually have functional specifications, though they're typically out of date, and they usually have no unit tests and spotty functional tests. There's another nice table in the NIST study that shows that defects that are from 440 to 880 times as expensive to repair in the operation and maintenance phase of a software applications life-cycle as they were in the original development. I think that's too pessimistic. I think that 80% is a good figure. In other words, if you spent $200k developing your original application, you should expect to spend $800k on maintenance programming and testing over the application's life span.

If you've got good unit tests, functional tests and functional specs, you might carve that down to 50%, in other words, expect to spend another $200k over the lifespan of the application. If you've followed an Agile development approach, you should be able to achieve those criteria. Your choice.

Related posts:

1. 800 on Your Math SAT, Software Development and Bugs
2. Agile Development Improves ROI – But RFP Processes are Stuck in Waterfall.
3. Cucumber Rocks – But it’s not a replacement for unit tests

Design patterns. I think they are the one of the most intriguing areas of object oriented application design and development. There are so many out there that can puzzle you each and every time you try to take a crack at them (I can name a few of them that I still can't figure how they are to be used or implemented).  But a thing that most programmers would agree is if used wisely and appropriately, these design patterns can provide really powerful benefits that can enhance one's programming experience and also the software that is being built. There are several patterns I have used/implemented in my projects that I think are awesome. I ll touch upon how I used some of them and why every Object oriented programmer needs to master them.

Factory Method

This must be one of the most commonly used patterns out there. We indeed have used it the most in our projects. The crux of this pattern is essentially delegating the task of creating objects to a method that basically takes in information about what kind of object is to be created etc.  There were a number of instances in the applications we built where there was a base domain object that had a bunch of derived types. In most of these instances, single method/interface that returned the base domain object type but created instances of the appropriate the derived type was used. The benefit? The object creator is decoupled from the users of the objects and makes the code more reusable and maintainable.

Dependency Injection

I m absolutely in love with this design pattern. It is a very effective design approach in my opinion. What it advocates is lazy/runtime injection of object dependencies or modules instead of hard-wiring them.  There are a number of third party dependency injection frameworks like Spring, Object Builder etc that let you implement dependency injection out of the box. A very simple example of how I used this on a recent project : Consider the application needs to talk to a remote service for what ever reason. We also built out a fake service that mocked the real remote service to enable us to test/run the application when the real one was unavailable or being developed. We needed a way for the application to swap dependencies (basically the real service and the fake one) at run time. Spring .NET's dependency injection enabled me to implement this.

Command Pattern

A really powerful design pattern that helped us a great deal in implementing an undo/redo feature  in one of our desktop application projects. The idea is pretty simple. Every operation that you want to be undone/redone is encapsulated in the form of a command object that contains information about the method or delegate that needs to be invoked for that operation, parameters for that method or delegate, the undo method etc. Every time, any such command is executed, it is pushed to an undo stack. If the command needs to be undone, it is simply popped off the stack and the undo method is invoked. There is a redo stack for handling redo operations.

Other patterns that I have used widely are the Singleton, Facade, MVC, Pure MVC and MVP. These are effective in their own different ways.

Related posts:

1. Using Design Patterns
2. Defining RIA Interaction Patterns on time in Flex Agile Development
3. Bean of the Devil: Why Getters, Setters and Such are Evil

I've worked on more than a few software projects over the decades and one of my favorite little misunderstandings is the Importance versus Effort disconnect. That's where non-experts assume that because a particular part of a software system is more important than another, it must also take more effort to develop. That is rarely the case and, in fact, importance -- however that is defined -- is rarely a driving factor in determining effort or cost. This sort of misconception can result in some planning and budgeting mistakes, sometimes to comic or even tragic effect.

To illustrate, I can point to a trading system that I worked on (the names have been changed to protect the innocent). The average size of a transaction in this system was over $1 billion in 1990's money. The part of the system that resolved the transactions was really really "important," but the part of the system that allowed an application helpdesk to support users by seeing what their user's saw cost 60% more to develop. That's right, an "unimportant" helpdesk module was more expensive and took more effort and cost more than the "important" backend that handled billions of dollars a day.

There are lots of reasons why one system can be more expensive to develop than another. One recurring and important reason is the amount of user interface your application has. By that I mean a user interface for a real flesh and blood user. One of the reasons that the above trading platform had this mismatch was that while the helpdesk app had lots of user interface requirements, the trading backend had almost none. It dealt almost exclusively with other systems through API's and data interchange protocols.

There's lots of empirical evidence that interfaces for humans are more difficult and expensive to develop that those for machines, but there's also a fair amount of theory on the subject under the heading of Human Computer Interaction (HCI). If you spend a little bit of time reading the referenced Wikipedia article, you'll see that there's an awful lot of cognitive psychology involved. In short, you can't just ask a human being to do those things that a software system can do -- parse 2GB of data, remember it forever and make decisions within a millisecond. No, human beings have limited memory, can't act very fast, have ambitions and emotions and all sorts of human frailties. All of these have to be accounted and designed for.

(We ourselves use an approach known as User Experience Design (UXD) to tackled this terrain. It's by no means the only approach, but it's stood us in good stead.)

So, what are the key takeaways for product managers and owners? Don't make emotional budgeting decisions. Just because your backend which is doing all of the financial transactions is important, doesn't mean that it should cost more than the nifty website that helps users buy your product or service. Listen to your developers and analysts on the subject of effort and cost, then make rational decisions based on what is essential for your business.

Related posts:

1. Software Development and the Construction Analogy
2. Software Development and Wasted Motion
3. Digging a Hole and Covering it with Leaves — The Software Development Version

photo credit: Sinaasappeljuice

At Pathfinder, we do our best to help our clients experience the software through the eyes of the user. Defining a feature includes explaining who will be using it, what they need to accomplish, why they need to accomplish it and how they’ll actually do it.

We start with personas (who) — they define the user base and let us identify the primary users whose needs we should focus on, which in turn drives the feature list. Personas also bring the human element into software development. Rather than using a vague term such as actor or user, terms that can easily be dismissed, we now have Myrna from Accounting, a numbers guru who is the primary user of the new software. Myrna is not so easily dismissed, especially once her needs and goals are identified.

We move onto user stories, all of which are written from the point of view of the personas:

As Accounting, Myrna needs to quickly extract time expended per project so she can calculate the actual costs.

Our user stories state both the user’s need (what) and business benefit (why) from meeting that need. The story is no longer some randomly floating idea; it’s now anchored to an identified user and given context within the scope of the business by specifically stating how the user and/or company can benefit from this feature.

From here we move onto acceptance criteria (how), i.e., defining how the user expects the feature to work. Since they’re written from the point of view of the user, they’re easy to understand and aid in experiencing the feature before it’s built:

Given that Myrna has clicked on Reports > Costing Report
   And that the costing report page has successfully displayed
When Myrna selects one or more projects
   And she specifies a date range
   And submits the request
Then the costing report will show the hours by project for each resource for the specified date range

Even without delving into the details (e.g., how does the user select one or more projects), you still have a pretty good idea of how someone will interact with this feature; i.e., you’ve established a foundation that interaction designers and information architects can now build on. Acceptance criteria, btw, are also great at uncovering any user story you might have missed, such as: does Myrna need to save this report after it’s generated?

Designing software with a user centric point of view begins with defining the Who (Personas), What (User Stories : User Needs), Why (User Stories : Business Benefits) and How (Acceptance Criteria) of feature stories. With this knowledge, we can then create a well-designed feature that we’re confident will meet the users’ needs.

Related posts:

1. It Starts with the User Story
2. Definition of a Feature (Given … When … Then)
3. The User Interface is the Root of All Evil

For new teams to Agile the statuses given in scrums are generally … well … lies. “Yep, on time. No obstacles.” I was once told by a colleague that, “You can’t hide on an Agile team.” This is true. However, this kind of exposure can be extremely uncomfortable for individuals to get used to. In traditional software teams people aren’t used to their peers asking them direct questions and paying close attention to their progress.

With some time and gentle nudging the team will begin to enjoy the help and support offered by a fully engaged team. The next pattern I see teams fall into is to try and solve any, and all problems, right in the scrum. When you hear about teams having trouble getting the scrum to fit into less than 15 minutes this is often what’s going on. When this happens the scrum master needs to remind participants that they can discuss the issues outside the scrum.

Once the scrums are moving well the next objective will be to facilitate good communication. Now that the team is really sharing and isn’t trying to solve the problem in the scrum, they usually offer to write an email/document/dissertation about the problem and possible solutions to get feedback. They usually do this to allow the others some space and to dive into the details. Why not just talk immediately after the scrum? Everybody is in the same place and thinking about the problem. If you are pair programming already, why not troubleshoot the issue together? If you aren’t pair programming start! If you really can’t fix the problem immediately due to a pressing issue you should schedule a meeting as soon as possible. If an issue is brought up in a scrum it is a blocking issue impacting the whole team’s ability to deliver the iteration on time. Its time to get all the help you can.  Good communication can help a team solve an issue in a matter of hours rather than days.

The result: Everybody’s time frees up and the “extra” meetings imposed by “agile” result in less meetings overall.

Photo Credit:
photos8.com under a Creative Commons Attribution License

Related posts:

1. We don’t have time for all of these meetings!
2. Agile 2009: A reminder of why each team needs leadership
3. Building a High Performance Agile Team: Assume You Will Be a One Hit Wonder

Vu360, the latest Pathfinder product, was launched by our client the Blue Book of Construction earlier last month.

It’s an Internet-tethered desktop application that enables easy viewing, markup and takeoff of PDF and TIFF documents for the architecture, engineering and construction industry. Some of the features include:

• Blueprints for projects seeking bids can be downloaded and annotated from the online plan room.
• Once a contractor is done annotating and marking up a blueprint, the file is easily saved back to the online plan room for viewing by the developer, general contractor or architect.
• While work is underway, the blueprint is saved on a users local computer. The tool does not require a persistent Internet connection to function.
• The tool includes a multitude of notations and graphing unique to the construction industry.
• The tool makes it easy to perform item counts and calculate length, perimeter, area and volume simply by drawing a square, line, cube or irregular, ad-hoc polygon directly on the blueprint.
• Sub-contractors can search BPM Select, Blue Book's repository of contracting supplies and products within the tool. When quoting installation of flooring, for example, a sub-contractor can link to a product sheet for the specific type of wood flooring they propose to use.

So far it’s been getting rave reviews from customers, including this one:

"VU360 is an incredible tool, and it’s sooooo easy to use. I cut back on my “job” estimate by at least 80% actual time. That would have been enough to impress me but, on top of that, I was able to export the figures to Excel."

We like those kinds of reviews. They tell us we’re doing something right when we design and develop software.

Vu360 is free, so if you’d like to download it and play with it, just go to the Blue Book and check it out. We’d love to get your feedback, so let us know what you think of it.

You can also check out the case study in our showcase for more project details and agile development goodness.

Our client, the Blue Book of Building and Construction also has a 40 minute tutorial for Vu360.

Related Services: PDF Application Development, .Net Application Development, Custom Software Development, User Experience Design

Related posts:

1. Launched: Rapid Reporting Employment Chek
2. The Desktop Application is Dead…Almost
3. Are You Building an Application or an Antique Web Framework?

I'm addicted to TED talks. There have been many nights where I've stayed up way too late watching them. For those who are unaware, TED is a yearly conference where world leaders and thinkers gather to share their ideas and spread their passions and work. I'm someone who gets fired up listening to outher people's passions. I love hearing about what gets other people excited, what makes them tick, what makes them want to share with the world.

One of the more interesting talks I've listened to recently is by Tim Brown at the Serious Play conference of 2008. Tim talks about how the elements of play can improve creativity and productivity in our workplace and life. I found the lessons learned from this talk something that can be very directly applied to software development, and taking some of these nuggets of teaching can help me be a better thinker and worker.

Playing a Game

The first exercise Tim does is to play a game with the audience. It's quite a
sophisticated adult thing to stand up on a stage and spend 20 minutes talking
about play, but it's another thing entirely to actually do it. Brown has the
audience perform several games. One of them: Drawing a picture of your neighbor
in 30 seconds. He does this primarily to demonstrate how adults are cultured to
shy away from play. After all, a civilized adult does not seriously use crayons
and markers to do any real work right? After this exercise he talks about how
when this test is given to adults, they often apologize to their neighbor, feel
embarassed, or otherwise don't enjoy the play at all. When the same test is
given to a group of children, they don't complain or apologize: They simply do
it and have fun with it. This teaches us a valuable lesson about how our
culture is geared toward play. When we're younger we go from schools that look
like this:

photo credit: LizMarie

And slowly we evolve to workplaces that look like this:

photo credit: Wyscan

This reminds me of the game that my colleague Michael Walkden played at Agile
Conference 2009. Participants are asked to build a building out of LEGOS, and
through this play, they discover some of the benefits of working with Agile
methods. When Michael was telling me more about his experiences playing this
game with audiences one of the questions I asked him was, "Don't you think if
we did this exercise with a client it'd be hard to convince them to take
playing a game seriously? Most people would see it as childish." To which he
responded yes, sometimes it can be difficult to convince a client to play and
'get into it'. There's a certain level of discomfort for play that we can have
as adults. We fear looking stupid, making a fool of ourselves, or getting too
caught up in what we think is the business of children. Michael went on to tell
me that once a client gains a certain level of comfort with playing, the value
gained from doing these kinds of exercises is enormous.

Modeling a Problem

Brown goes on to talk about the benefits of rapidly building a physical model
for a problem.  When we were children we learned by touching and doing.  This doesn't change when we are adults.  No matter how good we are at thinking abstractly as humans,
there's something about having a tangible model to work with that makes
us feel more connected to the work we're doing. Something to touch, feel
and hold brings great benefits to our creativity and imagination. This
reminds me of a neat talk I watched by Damien Katz, the creator of CouchDB. Among other things, Damien talks about when he switched to have CouchDB use HTTP and JSON what he felt like for the first time he could 'touch the data':

"I was so excited when I first started testing it out. Because a big
goal with CouchDB was that you would be able to feel like you could touch
your data, like it was right there in your hand. There're certain tools
where you have this responsiveness and you don't feel like there's all these
layers between you that are obfuscating what you're trying to get
at."

Isn't this something we should set as a design goal for all of our software
projects? Shouldn't we strive to have our users feel like they're in control of
the computer, and not the other way around? When we use tools that allow us to
quickly and easily touch our ideas, we reap the benefits of not only enjoying
our work more, but being able to flesh it out more quickly and productively.

In Brown's talk, he tells a story about how a group of surgeons were trying to
come up with a solution for a new surgical tool. They spent a good amount of time saying something like, "It's sort of like this tool, combined with this other one, but it also has some elements of this tool." Finally, one of the surgeons went away for a few minutes, and came back with a white-board marker taped to a handle and said, "Is it something like this?", to which everyone agreed, "Yeah, that's exactly what we need!". We see this often with software. "It's kind of like Facebook with a mixture of
Wikipedia, but it focuses around people who study animals professionally."
Wouldn't it be more powerful to have a working prototype to show what it is? To
let people play with it, to let them touch it and experience it rather than
spend hours in meetings talking about what it? When you're stuck in a waterfall
process, it can be easy to get lost in the weeds of abstraction and
uncertainty. Spending months designing specs and not making anything
'touchable' can be a long death march that leaves all parties unfulfilled and
unsatisfied. Let's spend our time making things that are fun to touch and play
with instead.

Moving Forward

So I throw this out as a question to everyone. What do you think about the
current state of play in the software industry? We've seen the power of play,
experimentation and fun in the free software world. Do you think it's relevant
in commercial software industry? If so, how can we break down barriers of
discomfort in order to encourage our teams to grow and play?

Related Services:
Agile Development, Custom Software Development

Related posts:

1. Agile 2009: A reminder of why each team needs leadership
2. What’s the value of Agile out of the box?
3. Advice to Developers: Try Understanding the Business

Ack! On the one hand, good for them for alerting me that an error had occurred. On the other hand, what's up with that message? I had no idea what I could do beyond clicking ok (and after reading the message I wasn't sure all was ok). A bit unnerving, but it did get me thinking about how applications deal with error messages.

The idea that non-technical users will be viewing error messages is one of those things that tends to be overlooked. You’re so focused on getting all the features up and working that dealing with errors on the presentation layer are often left out of both design and implementation.

Even if time is crunched on a project, however, here are three scenarios you should always cover in a user-friendly fashion:

Validation Errors

At a minimum, submitted forms should validate that all required fields have data and that certain data (such as email addresses) are properly formatted. My personal preference is to catch the obvious errors (e.g., empty fields) using client-side validation which gives the user instant feedback and allows them to correct their errors before actually submitting the form. Regardless of whether you’re using client or server side validation, however, you should still alert the user as to what went wrong — without using technical lingo — and highlight the fields containing the errors.

404 Errors

Design a useful “page not found” page. Make it as clever or funny as you like, but make sure you give the user alternative ways to find the page they were looking for so they don’t feel so helpless. This can be done by providing a site map, a search box or a list of top-level categories.

500 Errors

When a page blows up, unless you’re in a development environment you never want the user to see the stack trace. So, make sure that (a) there is a page in place to display when a 500 error occurs, (b) the app knows to display that page and (c) it gives useful feedback to the user.

In an ideal world, of course, errors never occur (ha!) but should they happen, your job is to let the user know what went wrong and provide guidance on the next steps. Time spent up front designing good error handling will alleviate user frustration down the line.

Related Services: User Experience Design, Custom Software Development

Related posts:

1. Oops! Our Bad.
2. Usability review: Amtrak.com checkout process
3. Stop, Reload, Error Loading Page 404: Converting Web 1.0 to 2.0

So, the question is: How to determine if your project/organization has that collective code ownership culture. And what team members (including managers ) can do to create/encourage it.

Does your project have collective code ownership?
Here are few things you may want to ask yourself to determine if your organization/project has collective ownership culture.

• Are tools like continuous integration and testing, code coverage and code metrics considered nice to have but not necessary?
• Is the project release schedule determined and then enforced with little or no involvement from developers?
• Is failure to slip on iteration stories viewed as failure on developer's part?
• Does your velocity seem to decrease with time?
• Do developers talk about my module, your module instead of our module?
• Do members aspire to leave your project and join other project?

If answers to these questions are mostly in the "yes" range, you may have a code ownership problem.

What's a developer to do?
Be a good citizen, strive to write good code. Leave any codebase cleaner than how you found it. Developer need to tame their tendency to guard their masterpiece code from other people's changes, infact welcome those. If you really really hate some design, try to pair with the person who concieved it and influence his thought process. This might be slow and furstrating but it will be better in the long term. If you rip out everything you don't like, you will end up owning everything. Remembership, it is a collective ownership. Code is very fluid, which means when coding, you can always take short-cuts to get stuff you are responsible for, done. Or you can take ownership and fix the general code quality (even if it take a little longer). These are all things that a developer is in control.

However, there are stuff that are beyond developer's control. It is hard to continue to be a good citzen when other members don't feel the same way and when your boss is holding your neck against a timeline. This is where managers can play a role.

Why do manager care about code ownership?
A manager cares about the quality of deliverable, team morale, attrition and deadline. An agile project manager can remote obstacles that prevent such culture from growing. Managers need to cultivate a culture where developers are not hard pressed to deliver on timeline at the cost of quality, atleast not often. Managers need to develop a culture of trust where developers are free to over-estimate stuff (atleast from their point of view). Hire team players overs smart but solo players.

What's a Architect to do?
Managers can't judge the quality of code and hence success of code ownership culture. Yes, there are code metrics like code coverage that attempt to quantify the code quality but those are not precise measures. Here is where architects can make a different. By architect, I mean anybody how has the direct or indirect authority to influence other developers and modify their behavior. Install tools like continuous integration, testing, code coverage and various other metrics. Encourage pair programming to reduce bus number and prevent knowledge silos (the bad side of code-ownership).

In summary, it could be a good thing when a team feels responsible when the project when in it and proud that they were part of a project that completed successfully. They owned the outcome of it, good or bad.

Related Services: Agile Development, Custom Software Development

Related posts:

1. What makes a good requirement document for an agile project
2. Data Driven Design and the Culture at Google
3. Code Coverage – Why?

Recently I had been wondering if Project Management was a questionable career choice. I have spent the last couple of years surrounded by talented individuals who seemed to be able to work fine without me. The test is always when the project manager (me) goes on vacation. Has the team fallen apart? Are they forgetting all of the practices they were doing? Is stuff getting delivered to clients? I was finding that I had a backlog of chores when I came back, but overall things were still humming along.

The Agile 2009 session reminded me of the road I took from software developer to a project manager and why. Early in career I generally found project managers provided little value. I asked a lot of questions and I caused a lot of trouble for those “managing” me. Eventually somebody said the equivalent of, “If you think you could do it better, do it.” No introduction to the subject tells you that, simply, good project managers are good leaders. They optimize what resources they have available, point out areas for improvement, and occasionally carry a stick. An Agile project manager, freed from the burdens of heavy process, can’t stay busy with chores long and must produce a good team quickly. I found that through focusing on how the team could work best together and gently pushing during retrospectives, I left a trail of happy teams on successful projects.

It may not be the most glamorous job, but each team needs one. To continue the sports theme from my last post: Most teams populated by very talented athletes. However, its take a good coach to help each of them reach potential together as a team. Now, back to leading my team.

Related Services: Agile Development, Custom Software Development

Related posts:

1. Building a High Performance Agile Team: Assume You Will Be a One Hit Wonder
2. Getting a team over the fear of daily scrums
3. What’s the value of Agile out of the box?