No Fluff Just Stuff, Central Florida Software Symposium

I went to the Central Florida Software Symposium over the weekend. It's a 3-day, Java-centric conference. Here's what I took away.

1. All the presenters are "agile" guys.
2. All the presenters are very interested in what Ruby and Ruby on Rails can do.

I got to meet and talk with a lot of really nice people. I met Bruce Tate, the author of the book, Better, Faster, Lighter Java. He's a super-nice guy; he let me pick his brain on a few topics. His conference sessions were all really interesting. Especially the one titled, Politics of Persistence. He gave us the break-down on all of different vendors who've twisted the various Java technologies out there to benefit themselves, but ultimately hurt all the developers. Here's a quick rundown; If a company is anywhere near Java, chances are they've screwed it up for their own gain.

I also got to meet a few people who are local to Central Florida. I have no shame, so I handed out my blog URL. :) Steve, Jennifer, and Ken: if you guys need any help with Spring, drop me a line. I may be able to help you with something!

microISV's, Don't forget to prototype!

Dimitris Giannitsaros (that's an awesome greek name if I've ever read one. Too bad I can't pronounce it! :) ), is trying to do what a lot of us are trying to do. Start his own microISV. His first product will be a CRM system. He recently posted about how he gotten some coding done. I left a comment that pointed him to a recent post of mine titled, "Taking a Step Back, Defining Users, Uses, and Building a Wireframe". (Which is me admitting that I got started with coding too soon and now I'm stopping until my spec is in order.)

Mr. Giannisaros says he is leaning more towards what 37 signals wrote about in their, "Getting Real, Step 1: No Functional Spec", article than what I'm advocating in my blog post, mentioned above. One line from his reply said something very revealing.

"I need to see things on screen, test them and often go back to the drawing board."

I agree with this statement 100%. But let us investigate the process of doing just that and think about the fastest way to get to a finished product.

Keep in mind the end goal is a finished product. For your own sanity, you'll want to work as efficiently as possible. You and I are trying to start a microISV. I'm sure the last thing you want to do is write code for 4 weeks (nights and weekends for us wanna-be microISV's, no less), only to throw it out the window when it's done and "go back to the drawing board". I've been there.

I remember back to one of the first web applications I built for my current employer. It was a seemingly simple photo album web site. I'll spare you the details of the requirements, but this is how our development process went.

We got an understanding of what the site was supposed to do, and wrote it down. Ok, so it's storing pictures, displaying pictures, and it had a few other features (again, I'll spare you the details). That's flipp'n easy, right? WRONG! The first version of the site was completed in 3 months. We then spent the next 5 months going around in circles because each time we'd show the business client what we had built they would say, "Ok, but what about this." We'd scurry off and build what they requested. Come back and say, "Here! We've built what we asked for." They would say, "Ok, but can we do this instead? We want it to operate like this...."

Every time we showed them our working web application (which was built to the SPEC!!!) they would realize it didn't have some feature or operate in some fashion that THEY JUST HAD TO HAVE TO LAUNCH.

It damn near drove me insane. Here is what I learned.

A human being can not tell if an application does what they want it to until they see it. No one can read a text document or have a conversation with someone and once finished say, "That's it! That's the app I want!"

I'm trying to build my own microISV and I'll tell you right now. I thought I knew what I wanted. But it wasn't until I saw the result of my code did I realize how little I knew about what I NEEDED to build. Project Management software, right? I'm a Project Manager. I know what to build. WRONG!

So how do you combat the I-need-to-see-it problem?

It sure as heck isn't ignoring the functional spec aspect of system development. It's making a prototype.

I define prototyping as creating mock-ups of every screen and screen state of the application you are building. (You can cheat like I do, and not make the form-error screens. So sue me! ;) )

You heard me right, every screen gets a mock-up. But here's the kicker. How do you know you've created them all?

I'll let you take 1 guess from the following:

• When it's dawn and your eyes are bloodshot from working for 24 hours straight.
• When you get bored of this "prototyping" thing.
• Whey you're just itching to write some REAL programming code.
• When someone yells at you, "You need to get started."
  
• You've identified all the potential Users of your system and have verified that they can now accomplish something useful with your application.
  

I once gathered the requirements for a charity-related web application (not a "web site", an actual "web application"). Each time we met I would go through the prototype with the client, trying to see if he could actually accomplish something useful with it. It took 3 or 4 iterations of the prototype before we finally had the screens in place for a system that would aid him in his work. In one of the later iterations we literally "discovered" a needed entity in the system. If we had missed that entity most of the original design of the system would have been scrapped. It was that drastic. In conversation the client thought we were taking it into account. But walking through the mock-ups of every single screen the User realized that he couldn't of done his job.

The first iteration of the prototype took a couple of weeks. Each iteration after that took a few of days to complete.

Contrast this with the photo-album web site, which is LESS sophisticated. Every time the Client saw the site, they wanted to move it in a drastic new direction. Each iteration of the system took weeks or months to complete.

Prototypes are quick, dirty, non-functioning, mock-ups of the system. They are as if you went into the future and took a bunch of screen shots of the finished product. Returned to the present and then wrote the system. How sweet would that be!

I can't stress enough the need for defining your users and creating a full and complete prototype. In my last blog post I mentioned wireframes as a stepping stone to prototyping. You are not required by law to make a wireframe. While you develop the app for your microISV no one is going to show up at your door and demand to see a diagram with a bunch of boxes and lines on it. But wireframing really helps you move from the user-definition point to the prototype point. (More details on wireframing from me. The first article I ever saw on the topic.)

Just in case anyone is curious, that photo album project didn't turn out with the world's greatest code base. Mid-project direction changes really hurt the quality of the code base. I'm actually working on re-doing the site from the ground up - 3 years later. And guess what I (along with the "new guy" I'm training) have spent the last 2 weeks doing. (Not every day, but a total of about 16 man-hours.)

We're writing out EXACTLY who the users of the system are and writing out EXACTLY what the users are going to be doing. We're currently working through a wireframe for each user type.

MicroISV's, don't fool your self into thinking that the whole app is "in your head". Force yourself to really spec everything out. I'm doing it for my Project Management application, and I already feel relieved. I won't be making functional decisions while I'm trying to write code!

You can make drastic changes to your prototype in a matter of hours. Changing code can take significantly longer. Your time is valuable. Do yourself a favor, work efficiently.

(Update 6/21: There is one more step before you're ready to do the technical work. Actually assembling the "spec". I'll write about it as soon as I've got the time!)

Now that is Entrepreneurial Inspiration - Commencement address by Steve Jobs

Text of Commencement address by Steve Jobs

What do you want to do with Project Management software?

Since I'm in the "defining" portion of developing my Project Management web application, Unity ™. I'd like to hear from anyone who has a suggestion for a feature. If you're using a PM app now and wish it did X, let me know about it. Please note that I am not offering any compensation for your suggestions and I may use your suggestion in my for-profit product.

Feel free to leave a comment below, or send me a private message.

Taking a Step Back, Defining Users, Uses, and Building a Wireframe

I've gotten to the point in writing my Project Management web application, Unity ™, that I'm making decisions about functionality and features while I'm writing code. In my opinion, this is a bad thing. A really really really bad thing. Having your IDE open while you're trying to figure out what the application should do is scary. You could end up with a ton of code written that won't ever be needed. Or once you're finished coding a feature you realize it's not that great, and you scrap it.

I spent the first 6-8 months of working on Unity ™ doing three things. Learning Java, figuring out how to store a tree structure in a database, and building a prototype.

(I define a prototype as all the screens of an application fully "mocked-up". The mocked-up screens display all the features and movements of an application, but they don't actually do anything. They are just dummy screens.)

All three activities were worth it, but I made a mistake in regards to my prototype. I built a prototype that I thought was about 80% complete. It had all the major pieces. I told myself that the other 20% of what I needed to implement I could just figure out as I built my app. I had all the details in my head anyway.

The problem is I skipped a few steps before the prototype. That "80% complete" has turned out to be only about 50%. And it's not that great of a 50%....

Here is what I skipped.

1. Writing out, on paper (or a word processor), EXACTLY who will be using my Project Management application. I had an idea, and I kind of knew the market I wanted. But "kind of" doesn't force you to think about the features you'll need to make your product a success.
   
2. Writing out, on paper (or a word processor), EXACTLY how the people using my Project Management application will use it. Again, I had an idea. But without it spelled out in black and white I never forced myself to think about all the features.
3. Building a full and complete Wireframe. I built a Wireframe that had all the major pieces, but I did it in the same "80%" fashion my prototype was done in. (i.e. - It wasn't done, and that 80% was more like 50%.)
   

(You can use a specialized tool, like Synthis's Adalon, or a generic diagramming tool to build a Wireframe. Visually, a Wireframe is a bunch of boxes with lines connecting them. Each box is a screen and each line is link between the screens. The link can be a hyperlink, form submission, or any other action that brings the User from one screen/screen state to the next. Each box has a description of what is on the screen.)

I really should have known better.

Over the past couple of weeks I've been working on a few things. Defining my Users, writing a story about how they will be using my application, and building a wireframe. These three activities have really focused my mind on the application I'm building. I've honestly discovered a couple of features that I must implement, and I've realized that I need to change direction on another major feature of Unity ™. (I'm intentionally not writing about what they are because I'm not close enough to shipping the product.)

Here are some tips for defining your Users and writing out how they use the application.

• Don't force your self into a rigid, "I must define all the Users before I write about how they use the application," mindset. Allow yourself to flip between defining what the Users are doing with the system, and who is using the system.
  

• After you define a few Users, write a story about them using the system. Do NOT write a feature list. A story about the Users interacting with the system in a typical work day will create a far more accurate needed-for-launch feature list than just typing out: Create Project, Create Task List, Assign Tasks, etc....
  

• Make your stories about the Users fun. Who cares if it takes an extra 3 minutes to write something like this:
  

"Monday morning rolls around and Peter shows up around 10:00 am. He slept in because he spent the weekend in Mexico getting drunk off cheap tequila.

Peter logs into Unity and notices that he's working on a Project called, "Skinny Jeans Product Launch Web Site". "Wow!", Peter says. I don't remember that Project. (Apparently when you mix cheap tequila with expensive mouth wash it affects your memory.) Peter sees that he completed writing a Site Definition for the Project and that his Client's name is Mary Client. Which he finds ironic, because she is his client. He also sees that he left himself a note to get started on the timeline."

As opposed to:

"Peter arrives at the office. Logs into Unity and sees a note to get started on a timeline for the Project."

You're going to be referring back to your stories at some point to extract your feature set. You might as well make that second read an entertaining one. (You'll remember the stories a little easier too.)

When I started mapping out my screens in my Wireframe, I literally read a few paragraphs of the story and made the Wireframe screens to match. Keep in mind that I've already coded a bunch of screens for my application. But while performing this exercise I realized that some of them may need to be tweaked. Since I'm taking the time to go back and create a real specification to build from, I'm not afraid to change things for the better.

To help you understand Wireframing a little better, here is an example of a Wireframe screen description. (NOTE: This isn't the actual description of my "New Project" screen. I've got to keep some of this stuff under wraps.)

Display form w/fields (# means required)
-*Name of Project
-Select List of Clients

If this form is arrived at from inside a Client Detail screen, then the cooresponding select list will be prefilled and marked inactive. (I.E. Can't be changed.)

This form can also be arrived at using a Global Command. The select list will be prefilled if the user is working within a Client Detail screen, but the select list will NOT be marked inactive. (It may not have been the intention of the User to use that Client, but it is nice to prefill them since that was the context they were in.)

This form will also have a button labeled "More Details". When clicked will open up the following form fields:
-Project Start Date (defaulted to today)
-Project End Date

When building a wireframe, I like to keep the descriptions short. At this point I'm just listing out what each screen will have on it.

I try to keep the User definitions, User stories, and Wireframe real loose at this point. Don't be afraid to make radical changes. That's the point of the exercise. You're figuring things out, not writing requirements for programmers to write algorithms from.

In my next blog post I'll talk about Prototyping and detailed Requirements. I'll also cover where I think you should really lock everything down.

Dating a Developer

I came across this blog post, and I had to share it. It's a few tips for women with programmers for boyfriends.

I've mentioned my wife a few times in my blog entries (and on other people's blogs), and I can't wait until she comes home from work so I can show her the link. She will definitely be able to relate!

Product Name Decision

In my last blog post I annouced that I had come up with the name, Uniti, for my Project Management web application. A 16 comment discussion broke out because I mentioned a few other names that were in the running, and a lot of people prefered one in particular: Projection.

First of all, I want to thank all of you for taking the time to weigh in on the debate. I read every comment and tallied up the votes.

Projection - 5
Uniti/Unity - 3 (including me)
Either would be fine - 1

I've spent a lot of time thinking about which name to use. My decision can be viewed as either incredibly stupid and ego-driven. Or carefully thought out and a sign of a person in command who isn't afraid to go against the grain of popular thinking. (Yes, a vote of 9 is enough to consider this entire exercie a sampling of "popular thinking"..... Ok, scratch that last "a person in command" line. :) )

I've decided to take the advice of the 2 people who voted for Uniti and go with the correctly spelled version, Unity ™.

Now I need to decide if I will use, Unity, Ataraxis Unity, or Ataraxis Software's Unity. I'm currently leaning towards naming the product just, "Unity". But refer to it on product listing web sites with the company name in front for the alpha-order bonus points.

If you're wondering why I went against the advice of the majority, I have several reasons. I mentioned some of them in the comments of the last post. But I'll spell out the biggest one here.

There are a lot of competitors in the Project Management market (which also means there are a lot of customers), and damn near all of them have the word Project or Task in their name. Projection would get lost in the mix. Simple as that.

A Name Comes Together

(Update 6/7: In the original version I used semicolons and asked if I was using them correctly. I wasn't, so I changed them to colons.)

I was writing a blog entry today about how I was still struggling to come up with a name for my Project Management web application. I've been entertaining a few names and I wanted to bounce them off you guys.

I had a suggestion from a friend: Projection. A recommendation from my wife: Projexis. And two that I came up with today: Projectile and Glue.

Before I could finish writing the entry my wife came home and told me we were meeting her parents for dinner. On the way to the restaurant I told my wife I was considering Projectile for a name. She liked the way it sounded, but thought I should spell it, ProjectIsle. Which really didn't make sense, but I appreciated her suggestion.

I started to steer away from Projectile. "Ataraxis Projectile" would be comical.

"The absence of mental stress or anxiety, hurtling through the air rapidly." - uh, no.

I also mentioned my other idea for a name, Glue. The look on my wife's face was like she had just stepped in something mushy, brown, and smelly.

We arrived at the restaurant. While we were waiting for her parents I kept going on and on about how I just can't come up with a good name. I mentioned how the night before I even considered, Amalgamate. A word I found when while trying to find something that meant "together".

Seconds after the word "together" left my mouth, it hit me.

Uniti

JavaScript, Wow, Damn

I recently discovered a web site that has some of the slickest JavaScript I've ever seen.

Wow. (I must warn you, if you start digging deep into this guy's web site you'll see pictures of naked women.)

I was really impressed with the polish of the menu at the top, and the black-box-thing he's using in this page.

I said, "Damn", in the title. Didn't I?

Unfortunately, the menu at the top doesn't even appear in Opera. And the black boxes have a different behavior in IE and Mozilla. In IE you can drag them around the page, while in Mozilla they can not be moved. (Damn!)

Like most of the web development community I have become more interested in JavaScript ever since Google released Gmail. I'm using some JavaScript DOM manipulation in order to make the task list of my Project Management web application easier to use. It's really awesome what you can do with the DOM API.

Then reality strikes and you realize you MUST DEBUG IN EVERY BROWSER. :(

I highly recommend reading everything contained on QuirksMode.com if you want to get crazy with JavaScript. It is a wealth of knowledge on the topic.

Slowed and Burned

I must admit, since I started this blog I haven't made a ton of progress on my Project Management web application.

For most of May, I was feeling really burned out. I tried to push through, but I just didn't make as much progress as I would have liked to. I also had to deal with an incredibly frustrating and time consuming Eclipse issue for the past few weeks.

Now, as if it was literally the month of May that was holding me back, I feel re-charged.

I put a lot of work in Tuesday and Wednesday of this week and moved past a major design descision that has been troubling me for a looooooooong time. I'm feeling good, and I can't wait to start my next work session!