Real World 2012

Real World is back and I am very excited.  It’s been quite a while since Real Software has put on a Real World and instead of being in Austin, Texas it’s in Orlando, Florida and the hotel is on the Disney property.  I expect to see a lot more families attending this year than in the past.

I’ve been to four Real Worlds and while I like Austin the conference tends to focus on the hotel and the immediate surrounding area.  This isn’t so bad but from a “new and exciting” standpoint there’s only so much you can see in the immediate Austin downtown area.  Orlando is definitely a destination city with plenty of things to do for the family, though us geeks (you’ll notice us by the pasty white skin tones) will be shunning the output of our local celestial star.  So not that we’ll see a lot outside of the hotel at least it will be different.

I am looking forward to this Real World for many reasons.  For the first time in several years I’m not the organizer of a Real Studio event!  Yay!  You have no idea how much work goes into an event – even those as simple as the ARBP events of the past couple of years.  I’m a coder not an event planner so I’m looking forward to JUST doing a couple of presentations.

I’ll pick up some new information and techniques in the sessions but I’ll learn the most by talking with other developers.  Talking about our shared experiences (both successes and failures) is rewarding and fruitful.  As with previous Real Worlds we’ll reacquaint ourselves with friends, colleagues, competitors, and future clients.  We have several current clients that we met originally at Real World so it pays to talk to as many people as you can!  You will never find a higher concentration of Real Studio developers at one time on the planet.

I’m leading a session on Real Studio consulting.  I guess I have a few things to say about doing this for a decade.  Seth and I are doing a session on Group Development using Real Studio.  Seth is doing a solo session on extending Web Edition with 3rd party services.   The agenda was just recently posted at http://www.realsoftware.com/community/agenda.php.

I discovered today that the kickoff session is by author Ken Whitaker who is an Agile Project Management expert and I’m so looking forward to it.  If you have not used Agile in a project I’d highly recommend attending.  We’ve used Agile on a big Fortune 100 prototype project and it was an amazing experience (due mostly to the Scrum Master leading the project).  I’m looking forward to his message and how we can improve our project management skills.

Most of us are familiar with the typical waterfall project where the client gives their requirements, we go code it and after several months of hard work we give them a build.  How often has your client said, “But that’s not what I wanted!” and you have to respond, “But that’s what you asked for!”?  Agile project management breaks it down into smaller chunks and is directed by the project owner.  In the long run the coders and the project owners are happier (I believe).  I’ll be curious on how Ken spins that for smaller development teams that are typical with Real Studio.

I’m sure Real Software will be talking, A LOT, about the new IDE, Cocoa, and many other things.  Having access to the Real Software engineers is a rewarding experience and buying a few drinks for them doesn’t hurt either.  😉

I’m sure there are still slots available.  I’d love to see you there.  More information can be found at http://www.realsoftware.com/community/realworld.php

Are you attending Real World?  If not, how come?  If so, please make sure you find me and say hi!

REALbasic on iPhone Debate

The March/April 2010 edition of REALbasic Developer Magazine hit my inbox this morning.  Besides the normal BKeeney Briefs column Marc Zeedar and I have a spirited debate on whether or not REAL Software should devote existing resources to making REAL Studio work with iPhone apps.

Note the italics on ‘existing’.  While I think it would be a nifty idea, overall, I question the wisdom of diverting resources from an already small development team to a product that might be doable.  Is this a Mac OS X only product or is it cross-platform?  I seriously doubt that it will be cross-platform but perhaps I’m wrong.  The point is that there are a ton of issues to figure out and then the question then becomes, “What are we going to give up in the desktop versions while this is being developed?”

Other thoughts:  Apple makes a boatload of money from developers buying Mac hardware and this product has the potential to take that revenue away.  One could certainly argue that it has the potential to sell more iPhones/iPads/iPod touches because more applications will be available.  But Apple has 140,000-ish apps right now.  Would 10,000 more, or 100,000 more really mean anything to Apple?

It also has the potential of being a potential support issue for Apple.  Assume for a second they allow RS to make iPhone apps.  The RB framework has a bug (because that’s never happened), or Apple changes the SDK one day and doesn’t give RS advance notice (Apple is secretive, no?), and now tens of thousands of RB iPhone apps no longer work.  Will the developer, RS or Apple get the blame?  Apple.  Just like how Microsoft gets the blame for crappy drivers and crappy 3rd party apps made by bad developers, Apple would get the blame.  Apple guards the keys to their kingdom very closely because they want it to be associated with a classy, premium product that “just works”.

Anyway, you can read the debate between Marc and myself in the magazine.  My guess is you can figure out my viewpoint.   😛  Marc argues, the opposite.

My regular column talks about making your projects more Agile-ish without going full-bore in using the Agile process.  It’s not as hard as you think and your clients might really like it.

Your thoughts?

No Face-To-Face Meetings Requires a Different Skill Set

I was reviewing this years client list and the work we’ve done this year.  We have a lot to be thankful for and we really appreciate their business and like to send them a small token of appreciation during the holiday season.  We hope they come back for more work and the gift, trivial really, is just a way of saying thanks.

I started thinking about our clients.  With the exception of a handful, most of them are not in the Kansas City area.  Heck, most of them aren’t even in the Midwest.  So what this means is that we never see our clients in a face-to-face meeting and have to rely upon phone calls (both traditional and via Skype), emails, instant messages, and the occasional screen share or video conference.

This makes managing a project harder in my opinion.  There is so much information that gets passed when you’re sitting across from a person that you’d be hard pressed to write it all down.  It’s hard to get that same level of info electronically.

I get a chuckle when I hear about companies looking to offshore their development work to developers in developing countries.  Sure, it’s possible and you might be able to save some money but there’s a hidden cost.

In an Cutter Consortium survey Link over 20 years and 8000 projects they found that offshore projects reduced the cost of projects to $3.2 million versus the $3.5 million it typically cost by doing it on-shore.  From a time perspective the on-shore project took 12.6 months and the offshore took 9.6 months.

The real kicker is that the defect rates for offshore projects were an incredible 7565 versus the 2702 for onshore projects.  So even though the offshore project cost less and took less time, the company had to fix nearly three times more defects.  In the long run I’m not sure the offshore projects saved anything.

In the same study Agile methodology came out looking like a winner.  The average agile project took 7.8 months with a cost of $2.2 milling with a defect rate of 1372.

Last summer we worked on an agile project.  It takes some time getting used to but after the initial learning curve the project went very fast and the client was very happy with the results.  If you have a big project you should probably think about using agile.

I apologize for digressing from the main topic.  Certainly one of the of biggest challenges with a long-distance client is communication.  I suspect this is why the offshore projects have higher defect rates.  Everything needs to be written down and communicated – mostly via email.  Throw in cultural and language differences and you have a recipe for misunderstandings (if not outright disasters).

A couple of things that I’ve learned is that the communication skill of each client is different.  Some can handle an email with a list of questions.  Others can’t so you end up with single point emails.  Email management is a must!

We use a bug tracking system and encourage our clients to log in and use it.  Most get it and love being able to track what’s been fixed and what hasn’t.  Others just won’t use it (despite regular prodding) and resort to emails.  Depending upon the size of the project, it might just be easier to transcribe those emails into your bug tracking system.

Long-distance clients need special attention.  They need reassurance that you are really working on their project.  For some clients we do a 3P report where we report on Progress, Problems and give the Plan for the upcoming week (sounds sort of agile, no?).  With the web becoming an integral part of our lives and business, learning how to work with clients from anywhere in the world is an important skill.

How do you deal with long-distance clients?  Do you try to have a face-to-face meeting with them?  Do you think you do anything special for your clients?

The Value of Rapid Prototyping (ie One of REALbasic’s Strengths)

Paul Buchheit (wikipedia entry) is the lead developer for Google’s Gmail.  In this blog post he talks about one of the things that he felt that Gmail did right and that was always have live (ie working) code.  Here’s the money quote:

The great thing about this process was that I didn’t need to sell anyone on my ideas. I would just write the code, release the feature, and watch the response. Usually, everyone (including me) would end up hating whatever it was (especially my ideas), but we always learned something from the experience, and we were able to quickly move on to other ideas.

If you’re still with me this describes the process we used last year on our big project for a Fortune 100.  In that project we used REALbasic as a prototyping tool and using the Agile process we spit out a major new release every three weeks.  Even in Sprint 0 (technically the planning sprint) we gave them a working prototype of our ideas.

In this regard, REALbasic excels.  Since the entire environment is integrated and the language is easy to use we were able to create incredibly complex user interfaces in a matter of days.  The end result is that we exceeded their expectations on creating a user interface that solved their problem.  This was, after all, why they hired our team because their internal groups had struggled for years to come up with something.

This company was used to web apps and we were obviously writing desktop apps with RB.  This was causing a ton of comments from them because they couldn’t think in anything other than a web app which we obviously were not coding.  So we took a sprint and took our desktop app and turned it into something that ‘looked’ like a web app complete with back/forward and home buttons.  This was easy to accomplish in REALbasic using Container Controls and a little bit of extra coding.  In the long run it accomplished the goal of creating a prototype that was more in tune with their expectations even though we never changed development environments.

Since the project was about prototyping a rather large and extremely complex user interface we had no real guidelines from the client other than this nebulous goal of fixing their problem.  One team member would do some layout sketches on paper (and later in OmniGraffle) and get preliminary approval from the client at the end of a sprint.  The developers would take the sketches and turn it into working code in week 1 of the sprint and turn it over to testing in week 2 and we’d do tweaks in week 3 for turnover to the client in the end of sprint review with what I (affectionately) called the developers “Dog and Pony Show”.

More than a few times we scrapped entire areas of code and completely rewrote it for the next sprint.  This meant that the clients gave feedback early and often and could get changes that didn’t mean anything to the developers, in terms of time, but helped them sell the project internally.  When the client goes into a meeting with a roomful of corporate vice presidents and during the obligatory PowerPoint demo they start chanting, “Demo!  Demo!,” you know you’ve accomplished something.

All in all, the project was a lot of work and what we gave them at the end of the project was only minimally what we showed them in sprint 0.  We could not have delivered as many fully thought out features without REALbasic.  It’s an awesome prototyping tool.

Agile Update

I admit, I was pretty skeptical when we first started our Agile project.  I still don’t think it’s the way to run all projects but for this one it’s pretty much the only way this project can work.

Why is that?  Gosh, where do I begin.  The client knows what they want…..sort of.  The sprint goals we had in Sprint 1 have morphed into something maybe not completely different, but they’ve shifted from a very narrow and specific goal to something a bit more broad and generic.  Or maybe a better way of putting it is that they started with goal A in mind and A has gone through seven, three week cycles of steady and incremental improvements so that instead of handling one specific scenario it can now support an infinite number of scenarios.  Some of the things we’re coding for now didn’t even come to mind until sprint 4 or 5 because the project owner didn’t even know they needed/wanted the feature.

Agile in this case is good because in traditional waterfall methodology we would have setup a big timeline with deliverables and gone away for 9 months, spend a couple hundred thousand (or more) and come back with something they didn’t want.  I live in a town (Kansas City) where that is the norm with a certain telecommunications company that shall remain nameless.  I dare you to ask any software developer or engineer that’s ever worked for them (and there’s a lot of ‘em!) and see if doesn’t work that way.  It’s a disaster and everyone loses in the end.  A lot of big corporation projects are like that I guess.

Agile is causing the client to rethink their internal projects.  They’ve even started moving some of their internal projects to agile.  However, with the thousands of people in their organization I bet there will be at least one spectacular failure because of the entrenched bureaucracy and it will give agile a bad name.  That’s my prediction only because the reason why it works for us is because we’re adapting as time goes on.  I’ve never met an organization that size that can spin on a dime.  Only time will tell if that prediction will come true or not.  Heck, I might not even be involved with the organization by then.

Agile has allowed us to do some fantastic work with the interface.  What their internal groups have struggled with for years, we’ve been able to incrementally improve during the course of the project.  One of the first comments we get from people seeing the prototype for the first time is how awesome it looks and how intuitive it is.

So how does REALbasic fit in?  We have been using RB to create incredibly rich and detailed prototypes which in turn is driving conversations inside the organization on the future of the project.  We have an interesting mix of mockups and real code.  The mockups are done first in a graphics program and the images are put into the prototype to show where we’re heading.  It has also provided an avenue to discuss requirements not yet defined and gives us developers a very clear direction on what to code.  It drives requirements which is interesting since normally the requirements drive the development.  So for us the prototype drives the rest of the project.

The REALbasic 2008 series has been exceptionally stable and secure.  The exception to that statement is Release 2 that killed us with the Windows apps not being able to catch nil object exceptions.  Otherwise, the number of bugs or limitations has dropped with each release and some of the newer technologies like introspection have started making its way into the project.  And since installation on the client machines is so easy (unzip a folder) we’ve not had too many issues.

The Quest for a Good Bug Tracker

Let’s start with the documentation aspect.  We generated 30 plus pages of assumptions, clarifications and questions from an 8 page document we received from the client.  The document we received is the crux of the project so it doesn’t surprise me that it generated that much.  In fact, once the client answers the questions it’ll most likely generate yet another set of questions.

It’s hard wrapping our minds around the agile process.  All of our documents are ‘living’ which means that from sprint to sprint they might (and most likely will) change.  Documenting the documentation changes is becoming important.  From my engineering days this is completely backwards.  Requirements documents were set in stone and were the bible and it took an act of God to change them.  So in the end, all of us are adapting.

Rally
Our agile tool, Rally, has some built-in defect tracking software.  We are now generating defects (i.e. bugs) in our prototypes and have to start tracking them.  Rally’s own set of defect tracking is severely limited in a number of ways.  It just doesn’t seem to follow the life cycle of a bug properly:  report-assign/feedback-fix-evalulate fix-close.  Their default states just don’t follow that and while I’m sure we could have added our own status’ I think our biggest limitation was the interface.

The interface just isn’t very rich and the Rally interface is just setup wrong for our needs.  They have the ability to add custom fields which is nice but their inline edit doesn’t always work the way you would like it to.  So you end up using the editor screen which is clunky:  it doesn’t expand to fit the available screen space and that means you end up scrolling to get to your required fields.  Slow and painful.

So I went looking for alternatives.

Bugzilla
Our Subversion host automatically gives us Bugzilla and Rally has an integration with Bugzilla.  This was my first stop.  I’m not sure why Bugzilla is considered one of the best bug trackers around.  I (and everyone else on the team) found it very hard to use.  Maybe it’s because all of us are Mac users and we just found it confusing.  I was tasked with setting it up and found setup to be very cumbersome.  The people entering bugs didn’t like it either and then the integration piece didn’t work so well in that there’s really two components of any bug (the fix by the developer and the verification of the fix by QA) that Rally doesn’t create automatically.  So rather than beat our heads against the wall any longer I did more research.

TestTrack Pro
I’ve used this tracking system before.  Unfortunately we’re using hosted servers (i.e. hosted) and there doesn’t seem to way to get this to work for us.  Everything I’ve seen on their website says that you need a dedicated machine for the server.  I even tried finding a hosted TTP and couldn’t.  Since I didn’t have a lot of time to set it up I gave up on this solution.  Perhaps when our QA team comes on board we’ll revisit this solution since Rally has an integration tool for it but it’s also a bit pricey and before I commit to it again I’d want to use it for a while.

phpBugTracker
I’ve never had good luck with this tool so I didn’t bother with it.  It’s been very buggy in my experience.  Other developers I know have had good success so your milage may vary.

Mantis
We’ve used Mantis for a long time.  The other team members have used Mantis on their other projects as well so in the long run this really wasn’t much of a contest.  When we made the decision to switch I had it installed and setup in under an hour.  The project setup seems to be especially easy to understand and use.  The Change Log is very handy for documenting changes in any particular build and we’ve found that the email process works well for us.

I must admit that the MyView page takes a while to get used to but once you ‘get it’ it makes life easy.  With one glance you can see issues assigned to you, unassigned issues, recently changed issues, issues you submitted and issues that you’re monitoring.

Maybe I like Mantis because its interface is compact and doesn’t require a lot of scrolling and clicking.  The interface just seems to be in the right spots for me.

I would have liked to taken a look at FogBugz (Real Software uses this) and others but time just didn’t permit.  Frankly, now that we’re up and running on Mantis it’ll have to be something compelling to get us to change.

I mentioned this in one of my RB Developer columns, but I think it’s worth repeating.  A good bug tracking system that is accessible by your clients, as well as your team, is very important.  It’s important not only from a development standpoint but from a sales standpoint.  When you’re making your pitch to the client you should mention that you have a bug tracking system and that they’ll have access to it and they’re expected to use it (rather than email and phone calls).  You’re helping the client see that you have a process for your software development.

What are your thoughts on bug tracking systems?

Agile Update

Nearly every project I’ve ever worked on (even in my electrical engineering days) has had lengthy requirement documents.  Whether I did it, the team did it, or the customer did it, the requirements documentation was generally the bible of what the project was going to do.  Changes to the bible caused change orders and resulted in large sums of money being thrown away.  In one rather large project I spent a full year on the requirements and documentation before I did any massive coding.

Agile is definitely different.  Our 5 person scrum team is working on 3 week iterations and we just finished iteration 0 meaning that all we did was figure out what to do in the next couple of iterations.  So we’ve defined what our epochs, stories and some of the tasks so far.  We’ve been using an agile tool from Rally Software that makes the process easier to manage.  Each iteration is planned out so everyone isn’t burned out at the end which is kind of nice (though I know we’ll have a few long days here and there).  At the end of the iteration we have show and tell with the product so the client can give feedback and review how well the iteration went.

The new iteration starts out with a planning session to identify all the stories and tasks your going to work on.  Then you start working on it.  So what this means for us developers is that we might be writing throw-away code and I’ve never done that before.  I’ve always planned on the code being their for all time.  This will take some getting used to.  It means that we only ‘know’ about the stuff that’s coming up in the next iteration or two which means that assumptions we make right now might not necessarily be the case in 6 weeks.

Of course, the whole point of the exercise is to get something to the client quickly so they can a) save money and b) have exactly what they want.  The traditional water fall method takes a long time and often times the results are not what the client wanted at all.  Living in Kansas City where Sprint is a major employer, it’s hard not to know someone who hasn’t been on a water fall project that took 2 years and was cancelled at the last minute because it didn’t meet the project of objectives (but still met all the requirements!).

That’s all for now.  Anyone else done an agile project before?  What was the hardest thing for you to get used to?  The benefits?  Drawbacks?