BKeeney Briefs

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?

Apple has xCode/Cocoa which they give away for free.  Microsoft has Visual Studio and .NET which can be obtained for next to nothing.  Both products create (arguably) superior applications for their respective platforms.

REALbasic  makes a consistently good application for both platforms.  Keep in mind that RB is nothing but compromises for the supported platforms.  The Microsoft MSHFlexGrid is superior in many ways to what the Apple grid can do so REALbasic has to compromise and give us the lowest common denominator in grids and hence we have an underpowered (but functional) listbox control.  The Einhugur StyleGrid and DataGrid controls do essentially that same thing just wrapped differently with some speed enhancements.

It’s been argued many times in the forums that RB doesn’t make a good Mac application without doing a lot of extra work.  The same is true that Windows applications made in RB suffer from some of the same problems.  Why is this?  Two words:  Cocoa and .NET.

Each frameworks gives developers goodies that highlight the strength of the platform and hence our initial question.  Does Apple or Microsoft really care about REALbasic?  It’s not like RB is going to see extra copies of Windows or sell more Macintosh computers directly.  If anything, you could argue that REALbasic hurts both Apple’s and Microsoft’s plans for “world domination.”

That’s a bold statement but here’s my reasoning.  I’m in charge of Apple the argument might go something like this:  RB allows developers to make software that works on my Mac’s and on the Borg’s own Windows.  I want to show the world that the better platform is the Macintosh so why should I help RS with any bugs on the Mac?  Now developers won’t use Cocoa and all the goodies that it has so all the time and effort to make Cocoa is wasted and our users don’t get all the goodies they’ve come to expect from Mac software.  RB is not enhancing my users’ experience!

If I’m in charge of Windows the argument could go like this.  I have this huge market share that’s being eroded by that toy computer from Apple.  Here’s RS that makes the claim of being a basic, object oriented, development environment that lets it easily create software for Windows and the Mac.  There’s even a utility that converts from VB6 to REALbasic!  Now people aren’t locked into Windows and all that work I’ve done promoting .NET is wasted!

Okay, both arguments seem silly but I’m sure the sentiment exists in Cupertino and Redmond.  I’m sure that neither company is actively sabotaging REAL Software and REALbasic but are they helping it?  In the world of business what seems like a win for the consumer is often perceived as a lose for the company.

What are your thoughts?  Is this idea possible or is it really stupid?  What am I missing?

Having your own business isn’t easy.  In fact, it’s the hardest thing anyone could ever attempt because the work never ends.  If you’re not doing ‘real’ work, you’re thinking about it.  How do you find the next bit of work?  What’s my next article going to be?  What product should I work on?  The questions are endless.

Our industry, in particular, isn’t known for it’s healthy habits.  We spend way too many hours in front of computer monitor.  My wife half-joked at last years Real World conference that you could tell who the programmers were because they were all pasty-white.  And that’s not a slam on anyone because she’s a programmer too and has been for longer than me.

Last Fall I was working a lot of hours.  I was tired all the time and I just felt miserable.  I was turning down work which is always a bad sign.  I knew I had to do something.

The first thing I did was hire an employee.  Some of you probably feel that’s a bad idea but I found an awesome developer.  In fact, he’s better at a lot of stuff than I am which is great because as a company I can now pursue projects that he wants to do as well as those that I have a passion for.  It also means we (collectively) can help out on some open source REALbasic projects.  So now, two of us can do more than just one of me was doing.  That was my first step.

For my second step I started going to the gym again.  I’m no longer funding a service I don’t use.  I go every other day and do a combination of weights and aerobic activity.  I’ve lost 15 pounds and I have more energy than I’ve had in a while.  Perhaps the best part of the gym is that I go to the office and do better code in less time.  My thoughts are focused and I’m generally sure about what I’m doing.

For many years I studied Aikido (earned a brown belt) and one of the many things I learned in its teachings is that Mind and Body are one.  Where the mind goes the body will follow and the reverse is true.  Where the body goes the mind will follow.  So if you don’t exercise your body you don’t exercise your mind.  I loved Aikido until my knees gave out but the truth still holds – you need to exercise your whole body.

Whatever it is that you enjoy that is not centered around the computer – do it!  If that means pounding nails while helping build a house, do it!  I know several developers/business owners that do that for fun.  Join a gym.  Join a league.  Go take a yoga or Thai Chi class.  Take an adult education class at the local community college.

Just do something different.   Something that’s NOT computer related.  Give your mind something else to ponder about for a while.  You’ll be amazed at how much better  you feel and how much better your code is.

So what do you do to refresh yourself?

I ran across this blog today titled Wide vs Deep and it got me thinking (which is always a scary thought). The blog is about how programmers are promoted to managers even though the thought processes are different. Managers are wide and shallow and programmers are deep and narrow.

While the article specifically references programmers that get promoted to managers I think it’s appropriate to talk about it since many of us are small business owners.  That means that we don’t have managers and programmers.  Forgive my poor English when I say, “We is it.”  So how do those of us that do both deal with being the programmer and the manager?

I’ll start off with a little bit of my background since I think it explains a lot about me and how I think about things.  I grew up in farm country in rural Illinois.  My role models growing up were men that with bailing wire, chewing gum and a welder could fix any piece of machinery under the sun.  None of them were specialists in anything and had a very wide grasp of reality.  They were tenacious and didn’t give up.  I think that’s the nature of being a farmer.

I attended an engineering college on the south side of Chicago just blocks away from Comiskey Park (and the Robert Taylor homes but that’s a different story!) where I earned a degree in electrical engineering.  Going to a private school was a struggle financially so I co-oped, did internships and worked my way through school in six years.  My education ran very deep and narrow in areas related to electrical engineering although you can argue that electrical engineering touches many areas of engineering (thank you very much for that lovely class called thermodynamics, by the way).

By the time I had graduated I had two full years of experience as an engineer and landed a great job solely because of my experience.  In my new job working in an industrial environment (steel mills and foundries) there was “the problem.”  The problem might be simple or complex, but it was my job to figure it out.  One day it might be fixing a glitch in a PLC program, looking at the circuitry of a steel hardness testing station, programming a new labor saving device or doing the load calculations for a new transformer.  The solutions involved researching the issue, evaluating the solutions, engineering the solution, getting the approvals to do it, and then do it!  I would call that the funnel approach since it starts wide and narrows down considerably towards the end.

As a software developer and the owner of a business with programmer employees I find myself being torn between being wide and deep.  I can’t do both at the same time and I can’t switch between the two quickly or easily.  When I’m in management mode I just can’t go deep without a transition period.  Thankfully, going from programmer to manager is an easier process even though it’s frustrating not being able to finish what I was working on.

From a project management standpoint I don’t need to know the details of the class/module that is being used or modified – I just care that there’s a solution.  But the programmer is concerned with the implementation details of that class/module.  They couldn’t care less (most of the time) if the customer is 30 days past due on an invoice or what the next project is.  They’re too deep into the details to care and, besides, that’s a “management problem”.

If you’re the sole developer in your business, it’s all too easy to miss the details or go too deep into the details too soon.  If you’ve ever been thinking about the code at the bidding stage and you’re designing classes or thinking about the details of how you’ll implement the project then you’re probably too into the details too soon.

Likewise, when you’re creating your bid, you can’t just guess at how long or much money a project should be.  You need to determine some of the details and maybe do some proof-of-concept programming before creating the bid.

So it’s not just as simple as being wide or deep.  You have to manage the process – especially if you’re on your own.  Here are some recommendations you can try.

1    When you first start looking at a project don’t go too deep at first.  Write down all of the major areas you (as the programmer) will need to take care of without getting into implementation details.
2    Identify those areas that you need to research and do some proof-of-concept programming.
3    Do your research and proof of concept programming but do NOT polish it.  Do not spend a lot of time on it, but also code like you’re coming back to it later (which hopefully you will if you’re awarded the bid).
4    Stop and re-evaluate your original major areas and assign values to them and finish your bid.

Once you have been awarded the work, you can use the research and proof-of-concept coding as a starting point.  You can start going deep into the details and code but keep in mind that the management of the project is not over yet.

As you gain experience it becomes easier to estimate.  You just ‘know’ that it takes a certain amount of time to do some task.  You’ve done it before and you know the pitfalls and complications that can arise.  (Shameless plug coming)  Use a product such as Task Timer to track your time.  If you don’t know how much time you spent on projects in the past how can you accurately estimate similar projects in the future?

In a future post I’ll talk about how to climb back out of the pit of details.  So what are your thoughts?  How do you avoid going too deep too soon?

Is the Internet Age killing civility?  I wonder about this a lot.  The REALbasic Forums and NUG posts are often filled with vitriol (always wanted to use that word) and personal attacks.  It’s as if the poster didn’t even realize that another human being is on the other end reading their post.

I’ve had bug reports that are very insulting.  Reporting the bug is one thing but often times the comments get personal.  I’ve had people swear at me in an email.  I think that they’re used to being ignored by tech support so they think that being as mean as possible somehow gets more attention.

In those few cases I simply put their tech support question at the bottom of the queue and deal with them after all the other stuff.  Occasionally I respond via email that real people read their tech support emails and that we were offended.  Mostly they write back to apologize.  Sometimes.

I can understand their problem to a certain extent.  When your software isn’t behaving and keeping the customer from doing their work it’s a huge problem.  If you’ve ignored their emails and phone calls then I can understand why they’d be rude but I pride myself in being responsive to my customers.  It takes but a minute to respond with a “we received your email.”

Generally phone calls go better because there’s an instant verbal connection.  We’ve also been taught since childhood to be polite on the phone.  Maybe it’s the lack of a ‘connection’ that causes the problem with email and forums.

A few years ago I was dealing with a developer out of California.  The other developers on my team hated dealing with “Jack” because he was always very rude, uncompromising and swore like a sailor.  He wasn’t a nice guy.

Jack called me one morning while he was driving on the freeway and started reading me the riot act and calling me every name under the sun and asking me why my code didn’t do something.  I was very mad and was about ready to tell him off, but decided that would get me fired pretty quick.  Jack was being unreasonable and not being civil so I simply told him to call me back when he wanted to treat me like a human being.

Silence and then an “okay” from the other end.  Jack hung up and I knew I was going to get a phone call from the boss.  Time to start updating the resume, I thought.

Sure enough, thirty minutes later my boss calls up – ecstatic.  “What did you say to Jack?” he asked.  I told him and all he said was, “Wow.”  Seems that Jack had been tormenting developers for years and it was even worse than I had been told.

Oh, and Jack called me that afternoon and apologized.  I never had a problem with Jack again.  The drawback is that I had to deal with Jack again and again because no one else wanted to.

How do you deal with the tech support emails and forum posts that are not civil?  Do you ignore them?  Do you let them know that their behavior is unacceptable?

People hate you if you’re a developer and you sell software.  Yes, it’s true.  Get over it.  No matter how hard you work at creating the perfect application someone will nit-pick something.  It doesn’t matter if you spent a year in development and six months in beta testing, someone will log a bug within the first 30 minutes of release.  Okay, the time frames are exaggerated but the end result is the same.

This means that you, as a developer, have to have thick skin.  Someone will always complain about something.  It happens all the time.  If you add feature X, users will complain that they “need” feature Y.  If you fix a bug and cause another one users will complain that your software is buggy and unstable.

If you panic every time you get a negative email then you’re probably in the wrong business.  Email is notorious for giving the wrong impression because you can’t tell if someone is joking or not.  Add the fact that writing is an art form that most people haven’t mastered and you’ll often misinterpret their intent.

Don’t even think about reading a review of your software by yourself.  Very few reviewers will give your software a perfect rating.  If they did, they wouldn’t be doing their job.  They get paid to point out a flaw, missing feature or bug in your software.  Have a friend or a spouse read the review first to get a relatively unbiased opinion of the review.  Then honestly look at the review and work on improving your software.  It’s an opportunity to improve.

Websites like VersionTracker allow feedback from users on software they’ve downloaded.  Be very careful when reviewing the feedback from those sites as generally happy people don’t feel inclined to give feedback.  Unhappy people like to spread their misery so bugs and missing features can cause a rating to go down quickly.

On the flip side, the next time you think about sending off an email or posting onto a support forum, think about how the developers might take your post.  Is it incendiary or is it respectful?  They’re human just like you.

Greetings and salutations!  My name is Bob Keeney and I’m the Vice-President of BKeeney Software Inc.  This blog was started after RBDeveloper magazine agreed to publish a BKeeney Brief’s column on a regular basis.  This is a very cool thing and I’m happy to do it.  I’ve always enjoyed writing and did a lot of writing for various Mac user groups back in the day.  On a regular basis we’ll talk about being a developer and what it’s like to make a living as a developer.

BKeeney Software does cross-platform application and database development using a variety of languages and tools.  We mainly use REALbasic by REAL Software.  REALbasic is to cross platform programming to what Microsoft Visual Basic 6 was to Windows.  In my opinion there is no other tool that is as easy-to-use and as powerful than RB.  Many critics complain that basic isn’t a real language when in fact (in RB at least) it creates a native executable for Windows, Macintosh and Linux.  And this is done with one code base.

RB isn’t a panacea for developers.  RB does a great job of making a decent application that’s reasonably close among all the platforms.  However, that means it’s not a true Windows, Macintosh or Linux application without a little bit of elbow work for each platform.

RB isn’t without its critics.  Some of the well deserved and some of them just petty.  Just as with any development environment, it’s easy to make a bad REALbasic application.  For those code purists out there, I’ve seen exceptionally bad .NET and Cocoa applications for Windows and the Macintosh respectively.  Let’s face it, a bad app is a bad app.

The trick with any development environment is to learn the little tricks of the trade the make life easier.  When I use Visual Basic 6 we have a bunch tools and routines that we’ve found over the years that helps polish an application.  Without them the application just appears “not done”.  In the accounting app we work on, we have close to one hundred Windows API calls that help out with one thing or another.  So it is with RB as well.  We have our classes and utilities and little helper apps that help us out.

One such help application we use with REALbasic is QuickKeys.  We set it up so that QuickKeys calls an RB Script that does any number of things.  One such thing is to add basic exception handling into the current method.  With a simple press of a button we add the name of the object, the method and a call to our global error handler.  It beats the heck out of typing it all in.

So what tools and utilities do you use for REALbasic?