Thursday, April 28, 2011

Today's two interesting observations

I had two interesting observations or experiences today:

1) While checking out at Lowe's in the self check out, I used a credit card. After swiping the card, I was then asked to enter the last 4 digits of the card number... I clearly had in my possession the card. Why wouldn't I know the last 4 digits by looking at the card? Seemed stupid. A good question, which I get at Marathon gas stations while swiping my card, is to enter my billing zip code address, which isn't physically on the card. It is on my drivers license, but then you would need to steal my wallet, with my license and not just my card.

2) I was in the bank doing a deposit at the desk. While waiting, I was looking around watching what people were doing. I watched an employee who was likely the "advisor" of some sort. While I was watching him, he was typing on his computer, a normal activity. But while he typed, he was looking down at the keyboard, single finger typing... How can you been in a serious position and not know how to type without looking at the screen? Sorry sir, your advice just lost value, go take a local typing class somewhere and then I will maybe listen to you. Learn the home keys. I was amazed. Typing should be taught in first or second grade now, I think I learned in 6, along with Oregon Trail.

Some simple stuff that bothered me today, had to let it out.

Wednesday, April 27, 2011

Too bad you don't know how to write software

Someone was talking to me about their business plans. How they have a site and some company put it up. They are selling their service and taking on clients, which is more activity on their site. But, they aren't happy with the support of their developers. It's hard to communicate issues and there is vague explanations of outages. Their company needs someone to get in there, take over, and be able to support, fix and grow the site. But they don't know who, or what company to consult with.

This someone was seeking my advice in the matter. My initial verbal response to him was, "too bad you don't know how to write software, if this were my problem, I would fix it myself".

I don't know how well this person took the advice, but it made me realized most business ideas solely rely on good technical talent. Not having this, or not knowing people to connect with is a major problem, and should likely be addressed sooner rather than later.

I never really understood why people majored in business in school, or spend time getting MBAs, seems wasteful. Technology is how you build these days, its not a physical store of merchandise, or a physical service. Services are digital, and are built on computer technology. Anyone can invent a business concept, not anyone can build that concept into something accessible online, or as software.

Why didn't I offer to help? I can do the work, but I don't want to right now. I am helping by the way, just not in a "builder" sense.

See Also:

Friday, April 22, 2011

I just learned about jQuery cloning

I was reading jQuery Fundamentals and I learned about $.fn.clone.

I thought, how could I use this? Well at the time I was trying to hold state of an object on a page at a specific time to reuse it later in a certain situation. The problem was, that object was being changed via different events on the page, I wanted a pure version of it. The object happened to be a form. So I cloned it to maintain the initial state:

window.clonedSearchForm = $('#searchForm').clone(true);

I stored the cloned form as a global so I could get it later. True is passed to the clone function as a deep copy. Then using it later:


I thought it was cool, likely not.

Javascript and front end code worries me

For whatever reason, whenever I look at front end code, I am agitated. Front end code to me is anything that is used to construct presentation to the user. This includes client side and server side technologies. For example, PHP is server side compiled but it presents content too.

A lot of front end work enables a lot of flexibility. Your page redering can be a single function, or not even a function. View pages can also be controllers as well depending on request parameters. View pages can return HTML, XML, JSON, etc depending on input.

Then I read Modern JavaScript, and I realized I am not alone in my worries.

As I am becoming more and more fond of Javascript, again I am worried. I see code all over the place. Functions that are a hundred lines long, no room for extension, scripts scattered across page templates, fragments and includes that render together as one. Where is the traceability and testing? In addition, I usually am not the original author when looking at bugs. I don't have the authors context and reasoning. I have to resort to the browser for debugging to understand how elements are combined and how they are dependent. Not the IDE, the browser.
  • When I see server side dynamically created Javascript, I am worried. 
  • When I see large DOM elements being constructed in Javascript and added to the page, I am worried.  
  • When I see more then one $(document).ready() in the primary rendering page, I am worried. 
  •  When I see a lot of global variables defined across includes, fragments and templates, I am worried.
  • When I talk to developers about bad Javascript and they tell me I should rewrite it if I don't understand it, I am worried. 
Hopefully things will get better, maybe they don't have to. Maybe developers need to grow up. A lot of code looks like "college code", you know, when you first are learning to program and hacked everything together? When you didn't debug, used a notepad editor and used logging statements for tests?

Thursday, April 21, 2011

jQuery plugin authoring internal methods

I was writing a jQuery plugin for the first time and the documentation didn't explain well how to properly implement internal methods to your plugin, verses external methods available to the caller which were documented. This is what I got working:

(Sorry for the image, I couldn't find a nice way to style code in Blogger)

Notice in the "return this.each" block, after "var $this = $(this);" a variable is defined as a function. This function is available in the main block as shown by "console.log(fooBar());".

Simple, but I searched around for a bit and didn't fine much. Maybe I have the terminology wrong.

Wednesday, April 20, 2011

War story advice, make sure there is somewhere to sleep

A good memory I have is during the the heat of battle (site launch), I found a team member sleeping in the workplace once.

We had be working late, nights and weekends. We were all burnt out, so eventually we'd go home, crash and get up and do it again. This guy was from out of town so he traveled in to work with the team during the tough times. He essentially carried the team as well, putting in extra, taking on the major load. He didn't have to go home when he was burnt, didn't really make sense since he was in a hotel. So he slept at work to charge up from time to time. We had a couch in the office in the kitchen, he made it his bed. He would also snooze in place in our war room, head back and snoring. Nobody bothered him, we let him be, gave him his time and then he carried on. No jokes, no comments, respect.

I did a similar move once, only at home. We were supporting an international client and we were always on calls at 3 in the morning. Some calls were long, remaining on calls during builds and job runs. I had a futon next to my desk at the time. So, during the call down times, I switched on speaker phone and snoozed for a bit.

I also rather then sleeping in bed at night, setup on the couch because I was expecting the phone to ring at late hours. This avoided me waking my wife. Getting in and out of bed during fire alarms didn't make her happy.

That's the advice, make sure you have somewhere to sleep during tough times.

Sunday, April 10, 2011

Ads Linking to Social Sites First?

I am a bit confused these days with advertising. Why do companies advertise to drive people to their social sites first? I don't understand. I watch TV and I see major retailer with links to Facebook and Twitter, not their direct sites. I watch news, and the shows tell people to follow them on Twitter, not goto the channel site first.

I do understand the value of social channels and building relationships with customers and a brand through which ever platform they use. I don't understand confusing the customer across a site (the main dot com or whatever), YouTube channel, Twitter feed, Facebook fan page, etc. All the social aspects should be channeled from the main site outward. Integrate these services into your site and then branch out. A good example is mentioned here around subsites, Top 10 Information Architecture Mistakes, look at number 5. What if you advertise on a channel, say TV, which I do have, and tell me to go to your social site, which I don't have an account for? This happens to me a lot, because I am not on Facebook, and I see Facebook links which I click and then require a sign in. At least make the content public verses private, or an account required to view.

Maybe this is too expensive for some companies, I get that. You can still take advantage of a platform and integrate that to the site, verse driving users to the platform then the site. You still need to maintain your data somewhere first right? Where are all the source videos you added to YouTube? Host them on the site. Where are the source images to posted to Facebook? Host them on the site. There are nice easy ways to have embedded video and have usable image libraries on a site these days.


These external feeds, or platforms, will not exist forever. Look at MySpace, it's dying. Remember AOL? Platforms come and go, but a direct channel to a customer or visitor should always exist as the center point. One thing that worries me, but I like at the same time, is customer service via Twitter. You have a problem, you interact with the company to get help on Twitter via their support account. What happens when Twitter goes away, changes, or becomes unpopular? Everyone that used that channel to get help, now needs to re-learn the process somewhere else. I would also like to know how the companies integrate the service data back into their enterprise for tracking and reporting? How do you tag my support feed with my profile in your organization to better understand me as a customer and the history I've had?

This goes for personal sites too, or bio sites if you will. I even get confused managing my own information. Right now, that center point is mostly this blog (one day I need a .com). Then I have a LinkedIn, Twitter, Flickr, Delicious, etc. I was watching CNN and Anderson Cooper has many ways to get in contact with him, he has two Twitter feeds, two sites, and likely something else I can't think of.

I would say in general, link to your dot com in your advertisements, not your social sites. But what do I know.

Thursday, April 7, 2011

Playing jokes on junior developers

Not so long ago, I was working on a project. The project was very review intensive, which I really liked. The more you can take a beating from your teammates, the better the quality your work will be before it hits the client. At the time I was the "technical lead" and another teammate was the front end lead. We also have poor junior developer.

Junior was working on some front end code. The review was assigned to the front end lead. The front end lead was swamped with reviews and his own work. So I thought I would pitch in and steal some reviews from his queue. One review was some work that junior did.

Initially I looked at the work and I thought it was ass wrong, just bad. So pinged junior and beat him up on it. Little did I know, he was working with the front end lead and was right (that is why I put the "technical lead" in quotes above). Fun part was, junior didn't know I knew he was right, but I talked with the front end lead and got a better understanding. Now that front end lead and myself are on the same page, we thought we would give junior a hard time.

So we switched gears. Front end lead changed his tune, and I was telling junior he was right and trying to force him to commit his code. Tough spot for junior, technically I had rank in the situation. What should he do? Ha, well we spun him in circles for awhile and finally told him he was good. He handled it well for being green, part time and the project was under a lot of "quality" pressure at the time. Likely not the best time to mess around, but oh well.

First time I really messed with anyone in a review, not too cool, but it was fun. Give it a try (just not on me).

Sunday, April 3, 2011

What I've learned from consulting (so far)

Few years back, I moved from a financial industry IT job to the consulting world. The agency I moved to at the time was local to the same area I already worked in. The sell for me to move over was that they were basically growing and needed man power. I didn't know what I would be doing, expectations, anything. I didn't have a role, an assignment, nothing. All I knew is that it was a young, fresh environment, which was very different than my internal banking position. You know a company is doing well when they just need help for no specific roll and times are good.

Regardless, I leaned a lot in my first few years. I wanted to dump and share what nobody told me about consulting and what I learned. Everything I mention is limited to mostly the web and commerce driven sites. This has been my primary focus for a few years now. The points below applied directly in my environment, and I don't know how applicable the concept and rules apply elsewhere. It's also my view and opinion. I am likely wrong in some cases and I will learn better later, or never.

1. Software Projects Don't Fail

I always heard in school and also at my first job that software projects fail. They start up, they get funding, there is design, build starts, and somewhere along the way, the project never launches. This doesn't happen in consulting, at least where I worked. You succeed in degrees. Meaning you never complete anything, its always going, and therefore you never fail. You launch, otherwise. you are out of a job, there are no options.

2. Launching with a bug list

I always thought software went through a very refined and vigorous testing and launch phase. We are talking about something that millions of people will use and millions of dollars will be made from. I thought, a launch has to be perfect. I soon realized, that if this were true, then number 1 is then possible, which it can't be. Products are lunched with a bug list and are never perfect. They are good enough and are fixed later.

3. Formal technical documentation is in general useless

Similar to number 2, I assumed documentation is was a huge necessity for software. Its not. Smart people are good making sense out of nothing and nonsense. I think code, scripts, configurations, etc should be self documenting. Initial design and approach is important to spawn ideas and think out where you might go with a solution. Writing this all down and formalizing before implementation is a waste. Why? You design is likely wrong, not wrong in the sense that you are stupid, more is understood as you go. As you are going, time to go back and update formal documentation is slow and painful. Plus nobody is looking at the documentation anyways.

Like I said, your technical stuff should be self documenting. Use good naming, comment inline, be kind to developers that are going to have to read your work.

4. Formal functional documentation really matters

Number 3 does not apply to functional documentation. Functional in the sense of use cases, stories and business rules. These need to be hammered out and finalized per spring, build cycle or release. Changing functional details mid stream is the death to completion. I understand something changes, but you cannot allow functional level specs impact the sprint agreement, its the only way a sprint is a sprint.

5. Gut check work breakdown is good enough

When planning a large project, you would think after functional level design is completed, technical implementation design is completed and then the work is well understood and therefore proper estimation of work can occur. Since technical design is again in general worthless, you can't estimate properly. If you spend too much time doing technical design without implementation along the way, you've likely designed down a path that is wrong and change, and your specifics on work break down are already incorrect. The work breakdown can be a gut check after functional agreement. How do you gut check?

6. How to estimate work (or gut check it)

Nobody in school tells you how to estimate work given vague details. This is all about what number 5 is about. Its simple as problem solving. Break the problem down into minimal meaningful chunks. Each chuck should be somewhere in the range of 2,4,6,8,10 hours. More than that, break it down more.

This exercise might be wrong, you might be right, regardless, it helps you break down the problem into small pieces and tackle the solution in chunks. Even if you aren't responsible for estimation, its a good practice to take an assignment yourself and break it down from an approach perspective.

7. How to go live

Going live on the web is tough. Nobody told me this. Nobody prepared me for it either. Plan for 6 months of hell. Nights and weekends are gone. You won't see much of your family or friends. You need to pack in with your team, work close and break the rules. There are likely process and procedure in the release process. There is likely a date that everything is due. I am not sure why, even if everything is planned, and work is well understood, projects fall behind. But, as I said in number 1, they don't fail. Therefore, rules are broken. The team will naturally form self productive habits and their own procedures to help get to the finish line. This should not be messed with. If the project needs to go, then whatever it takes needs to be allowed. You will likely find true and useful patterns fall out of a team going live. Compare them to what your organization really does. The comparison I bet will show what is wrong in your organizations operating procedures and demonstration opportunity for improvement.

You also need to manage your client for going live. Shit is going to be wrong, and as in number 2, you are going live with a bug list already. Text alignment, images and styling are not show stoppers. Get the damn site up, start making money and fix it later. The technical team will not manage this, you will need a seasoned PM or client manager, without it, you will fail by pure escalation on the client to put the breaks on.

8. The go live date will move

Despite your best efforts, your launch date will move. Again, manage your client, put your head down and go. There is no worth in assigning blame in the process, get live, then figure out what when wrong and who pays for it latter. Stick to your guns on your functional documentation, number 4. These are the agreed upon site functions, if these change, you need proof of scope change and you need to hold your client responsible for the impact of the miss or change.

9. Logging really matters

You are going live with a bug list remember? Those are your known issues. On top of that, a bunch of shit you never thought of is going to fail. This is when your logging really matters. You need to be able to enable / disable logging on all your logic, including client and server site. Client side, use some JS console logger. You can also log client activity to the server with fancy solutions. Log data transformations, before and after. Log arithmetic. Log counters. Log array indexing. Log method entry and exit methods. Catch exceptions and log as much data around the exception as possible. Formalize key failure logging strings for monitoring and alerts. Doing this before a problem is incredibly valuable. Getting code changes in around a problem when it occurs just to add logging means you didn't do your job. Someone tells you your logging impacts performance, tell them to shut up.

10. Code review everything

I've learned so much from reviewing other people's code. I've caught so many of my own bugs walking someone else through my code. I've seen so many bugs when looking at a DIFF. There is no possible way a change can go live with two sets of eyes seeing the change and working through the problem. Even good technical people make mistakes. We are going live remember? We are working nights and weekends, we are going to mess up. The review doesn't have to be formal and should be desired,  you need to want people to beat up your code. It only makes you better and stronger. Build it into your process, add options for passing and failing.

I keep saying code, but review everything. Configuration and scripts count.

11. Performance and load testing is not optional

I've done launch without proper load and performance testing. You cannot assume anything. Unless it's measured, you dont know anything. Think your existing infrastructure and configuration can handle additional traffic? How do you know? You need to measure it.

12. Failure is good, do it fast

Shit is going to fail, I mean fail. Site will go down, users will complain, money will be lost. These are all very bad. How do you prevent it again? The failure needs to be well understood. It needs to be embraced like a success. It should be documented, presented and well explained. Tell your friends, tell your mom, tell your customers. You will talk about the failures of your work much more than the successes. You'll learn so much more from screwing it up, doing it wrong and fixing it.

Just remember to fail fast. Again, so long nights and weekends, you need to get the site back up and fixed. Put your game face on, and do it. These are your war stories, the death march. You can be a hero. Its the IT football field, its overtime, your team is down and the team needs you.

13. Be ready to rewrite an implementation

Scaling for growth is inevitable, but doing this upfront for extreme situations doesn't make sense because you don't know to what extremes. Expect your implementations to have a breaking point, it will stop to work at a certain load level and will require to be rewritten. This is a hard place to fail fast in, but if you use proper measurements, you should know when your current solution will stop working, and when you start planning to get ahead of it. If not, you likely will need to patch it with something dirty in the mean time to get to an actual fix.

14. Dirty is just fine most of the time

Well crafted algorithms and process are really cool, but usually some duct tape, smoke and mirrors will do just fine. Why? Because the dirty work will likely handle solving a problem with no negative affects for awhile, or forever. Think about the time you saved it your solution stands up forever that you designed for a few hours. Plus, once it breaks, you need to rewrite it anyways. We aren't building a house or a bridge, we're building software, web software. Technology doesn't need to stand as a structure for hundreds of years, platforms change within 5 years and you need to keep up anyways. Don't kill yourself over engineering a solution. Break out of your framework or stack, get the tape and make it happen.

And that's it... I likely forgot something, but this is a good start. I still am doing consulting work. I like being on the front lines, I like the thrill, I like fixing disasters for some reasons. I don't like giving up my whole life, so it's tough sometimes. I've learned that in order to put up with such demanding role, you need to take back what you put in. If you can't, you likely need to move on before you lose your personal life.

Share on Twitter