Developer Phases

1. How do I do that? (Entry)
2. Yeah, I can do that. (Mid)
3. Sigh. What was I thinking when I wrote this? (Adv)

HQL vs. SQL

I've been playing with HQL for awhile now and want to share my thoughts of it against SQL. Some developers are hesitant to switch to HQL because of the querying. I don't blame them. Writing HQL can be tougher than SQL. After fighting threw some HQL queries I have found that SQL still has its place in an HQL application. Here are some of my findings:

1. List pages and aggregates are faster and easier to write in SQL. Most of the time the data points that list pages and aggregates are going to be displayed are already hashed out and don't need to be changed much.

2. HQL is great for getting and setting simple data quickly. SQL takes too much energy and time to insert or get a piece of data. The SQL queries you write are not going to be flexible enough for the new fields people are going to request.

3. Some routines are more efficient to be ran in SQL. HQL can be slow and it brings back too much data sometimes.

With the above findings I have organized my code to do saves and single entity gets with HQL and lists and routines with SQL. With this combo I have found it to be quick to get and set the data I need. It does take knowledge of both HQL and SQL to do this, but the languages are very similar and the learner curve isn't too bad. Here is an earlier post about the similarities. I hope this brings down the hesitation for the SQL people to try and use HQL for what it's good for.

I would like to hear peoples thoughts on this matter. It seems to come up a lot in HQL conversations, so comment away.

CSS hierarchy wish

Alot, of times I find myself having a wrapper around some elements in my html so that I can do some custom css inside of it. In the css case below the wrapper is a div with a class of "webfolio".

div.webfolio h3{
font-size:1.5em;
color:#333;
}

div.webfolio div.article{
border:1px solid #666;
}

div.webfolio div.description{
color:#555;
}

Notice I have to write "div.webfolio" over and over. I just want to write it once, with everything (it's children) inside of it. I wish I could do it like this:

div.webfolio{

h3{
font-size:1.5em;
color:#333;
}

div.article{
border:1px solid #666;
}

div.description{
color:#555;
}

}

I just feel dirty writing the same name over and over. Yes, I realize if you get more than one or two deep in above css it would get harder to read. In a perfect world this could be prevented by code responsibility.

Just Do It : Programming to the Nike Approach.

After reading a recommended book by a friend, I wanted to talk about the Nike's old marketing slogan, "Just Do It.", and it's relationship to my programming experiences. Nike's "Just Do It" slogan really helps me answer those 50/50 questions or "hmm, we could probably use this snippet of code in other places, but I am not sure if it should be reused" or "this might be a pretty good idea, but I am not sure if we have permission to do it." you have when you are programming. Do what you think is right. Basically, JUST DO IT! There have been so many times another programmer or myself have been stuck or afraid of making a business decision becomes of fears of the wrong outcome. The fact is "no one likes to make decisions" period, so presenting it to another person really just causes frustration. So just code it the way you think it needs to be done.

Now, I am not saying you should do this for ever decision but most of the decisions left up to a developer are minor in the eyes of the user. They want you to tell them how they should work and they will tell you what's missing, named wrong, or doesn't work. So I invite you to be bold like Nike and "Just Do It.".

Throw that extra icon or link in there.
Set the smart default you think you would use the most.
Constrain the user to a set of options to choose from to better focus the experience.

Once it's coded and demo-able, have another couple set of eyes look at it. They will tell you what works and doesn't work, but at least you create some discussion on your concern by showing. Showing is such a strong yet hard thing to accomplish in programming, because it's hard to finish something. By getting something to show you are very close if not finished with your task. People aren't dump, they will notice the changes you did and if they don't that means they don't care and your in the clear or you chose "what the user will naturally want" and it will work. Either way it's a silent win for you.

If you spend too much time deciding how something should be done vs. doing it, more and more requests will be added and you will get overwhelmed with tasks. Just code it and demo it to a group of people, whom will spend the next week ripping and tweaking the piece you created, until they figure out what they want. Where this kinda sucks cause you will have to go back and look at your code, you will find out what worked and didn't, be able to create some direction for your self by involving others in your concerns, and be more prepared for the next task for which you can transfer the tips you learned. It also allows you to focus more on code instead of managing politics.

In recap...Just Do It!

Simplicity vs. DRY code

I was in a pickle today over whether or not to consolidate code or keep it a little bit wet for simplicity sake. I consider simplicity sake, going to a view and not having to unlock the rubric's cube of "if" logic. If you are not familiar with wet and dry code, wet is where you repeat yourself over and over and dry is where you "Don't Repeat Yourself (DRY)". I went with "Simplicity". I decided to consolidate parts of the view, yet repeat myself a little. I found this to be safe because I felt like the views would grow and I didn't want it to end up with a crazy page that only the maker has the key to unlocking its craziness. Yeah, we have all seen some of those old pages that are a disaster to debug and I didn't want to start that trend. Also, I wanted the next person behind me to get in and out of the view as quickly as possible. It wasn't very much fun going through every view and updating the same piece of code...but it was simple.

Small == Big

Have you ever tried to over architect something so that it fits all cases and solves world hunger?

I think we have all ran into this problem before and I think it's due to fear. We are afraid that the wierd, the one-off case comes along and we have to re-work our code that we spent so much time and thought into. Let's be honest no-one likes to go back and repeat something all over again, just because of one little feature/request. Sadly, no matter what you do, it will quickly become out-dated and need to be looked at again. On the flip side, the cool part is that you get solve the issue in a new way.

One thing that helps remind me not to over architect something is to start small. Solve your issue for one record. Example: "Add one user to the system". Solving for one record helps you identify the core pieces that make up the record.

Next, go back and tweak your code to do a group of records. Example: "Add a group of users to the system." Processing records in a group helps save the end user time.

And finally package your code, if you it's generic enough, to be used by other systems. Packaging helps the next developer who needs to solve a similar issue jump start there development efforts and gives them a feeling of "safety net" that someone else can help them if they get stuck.

Going back and touching your code sucks but it can be made more fun if you try to solve for the group of records and packaging. It will help you discover a new solution to your issue and keep you interested in your re-work.

Remeber:
1. One record
2. A group of records
3. Package it for the next developer

Break it up

I attended an Adobe MAX session a few weeks ago (The Business Value of User Experience) and I began to relate to some of the struggles that others have had with interfaces and user experiences. Things like how to accommodate multiple types users and guiding users through processes are the major points I picked up from the session.

Handling Multiple User Audiences.
We have all ran into this issue before and if you haven't...you should. How do we handle power users vs. regular users? Power users are the small group of individuals that are going to stretch the app to the boundaries. Regular users are going to do their tasks and are usually just looking to get their "computer work" done asap. So how do we address the power user's needs without confusing or frustrating the regular user's UX? How do we break up complex problems when we code? We break up the code into smaller, more manageable chunks. So we break up the UI when we have complex options or features.

The biggest thing to remember when handling multiple audiences is don't wreck the majority audience's UX. If you need to implement extra options or features in the UI for the power users, separate them from the core options or features. What I am saying is only show what is needed and have a place separate from the main screens, to make the options available for the power users. The power users will find those options, they don't care where the options or features are they just needed the ability to have them. The regular users don't care about the extra options or features and don't even need to know about them. Keep the regular users processes straight forward. Aim for no frustrate or hassle with them. A good example of how to implement this is do what MS did. They implemented an "Advanced" option, usually in the navigation form of a button to hide all the extra options and features. Another word that works well is "Settings".

Guiding the User.
We have all been guided through wizards that we click "Next...Next...Next" all the way through. This is a great way to walk users through a complex problem. But sometimes users don't need a multi-screen wizard to walk them through a process. Sometimes they just need some clarity or steps to verify against as they complete a screen. A good way to do this is by displaying a vertical wizard. A vertical wizard doesn't have to be a complex process that the user is being walked through. It can simply provide clarity to know that what they are filling out is used for something. A good example of this is Campaign Monitor's sign up wizard.

A last random note is to remember that your users are people. Remember that people hate making decisions, but always want the decisions available.

Robot Coders

In most trades people do what they are told, it gets done, and life goes on. Development requires you think into the future to prevent issues, which may bring a developer to challenging the validity of the task. Challenging a task could potentially bring up new ideas or issues. I am not saying challenge every thing that is assign to you, but do a quick check against the current state of the app. A quick check could create a new module or even a product. It could also bring up trickle down issues that may occur from bringing in a new change or feature.

From what I've seen so far,in the 2 years of coding, is that some developers are mindless coders. They are like robots whom take input and return results. While management loves this, development hates it. The problem with coding this way is you get crap code that only serves a one-off purpose from either a quick decision or sales promise and harms the purpose of a feature or even the app. I just think things should be thought through a little more before they are coded up, and it is the responsibility of the coder , as a last resort, to take care of this. I am not asking for a design meeting, but 5 to 10 minutes of quick thinking or maybe a peer's opinion may bring something important up that will save time and money in the long run.

A few things I do before coding something up are:
1. What parts will be affected?
2. Will this change the current purpose of the code in a way that is not desired or maybe interpreted incorrectly?
3. How much code do I need to change?
4. Do the database relationships support what I am going to do?
5. Do I have the time to make the changes without throwing some spaghetti code together?
6. Will my changes effect/prevent someone else's ability to work?
7. Do I need a hand with the design or amount of this task?
8. Are the changes worth my time right now or are there bigger fish to fry first?

These are just a few things that go through my mind before I begin a task. I think the robot coders should become human again, by learning to think outside the box or for themselves and not by an outside entity. What goes though your guy's mind before you begin coding?

The litte things

As I logged into my bank accounts online I realized how much of the little things are missing from a page. Details such as label tags on radio and checkboxes, titles on links, and directions steps in a wizard are just to name a few. When working with presentation, people remember every little detail. So remember to think of the little things.

ColdFusion and PDF font-size pt vs px

So a few months ago I was walking by a developers desk and stopped when I saw him frustrated with some ColdFusion PDF output. He was working with font size's in using pixels (Ex. font-size:15px;) and it was not rendering the same in FireFox and IE. I sat down with him for a bit and we both thought using pixels instead of points (Ex. font-size:15pt) would be compatible across browsers. Our idea was wrong. I went back to my desk and played around with the compatibility of different pixel sizes in the two browsers but had no luck. Giving up with the pixel's idea, I then tried pt. Using pt worked far better then px when dealing with PDF.