Mac World 08' - MacBook Air

Yesterday, Mac World 08' kicked off in spectacular glory. It was phenomenal as usual. Steve Jobs just has a way about him, that instills with you with the utmost confidence that Apple will never let you down. Every MacWorld I remember has lived up to some sort of hype going all the way back to the iPod. If you haven't already seen it, you can check it out the keynote here. He had four agendas to share with the public.

1. Reveiew of 07' / Lepoard
   
2. Iphone/Ipod
3. Apple TV
4. Air

The most interesting topic was the MacBook Air. It is the slimmest notebook in the history of laptops weighing in 3.0 lbs, and less then an inch thick. It can literally fit in an office envelope. You would think at this point, what components of the computer did they compromise in order to make this notebook so small? Nothing. They didn't compromise anything. They have a 13.3" screen, 2GB RAM, 80 GB hard disk, full size keyboard, and a full size display. What about the processor? It's a 60% smaller core 2 duo! Intel really pulled a rabbit out of a hat with this remarkable work of engineering. In fact, the whole electronics of the MacBook is as long as a pencil and as wide as a crayon. Just incredibly small.

Good work Apple, you keep finding ways to entice me into buying your products.

Agile Development Demystified

If your a software developer, you have undoubtedly come across this term at one point in your career. You may have heard such things as, this development methodology will help organize software development into more lightweight, manageable development modules. This, in theory, will increase the time to market for the product that you have just spent a lot of developer coin on. Is it reasonable to want to spend your developer coin efficiently? Of course it is, especially if you can get to the market with your product in a cyber world that punishes the late comer. Well, I would like to spend some time with you today giving you my own take on what agile development is, from being immersed in it for the past 40 days, and through one book.

I have always heard the term agile development, but never had a clear vision of what it was. These methods were explained in synonymous terms in my software engineering course. It was described merely as an iterative process. That really doesn't explain what exactly agile development is. So what is it? In simple terms, agile development is a process where you do many of the little things to aid in the efficiency of developing software programs rapidly.

Kind of a vague definition. Let me give you some concepts that would be considered agile.

1. You work closely with customers
2. Clear, presentable and maintainable goals
3. Development happens in iterations or cycles
   
4. Collaborate with members of your team to solve problems
5. Ability to respond quickly to ever changing requirements and customer demands
6. Accurate estimates of software completion
   

Now, that is not all what agile is. That is just the beginning; a taste of what an agile project feels like. Agile development requires a highly cohesive group of people, committed to coming up with schedules, collaborating with one another for problems and code reviews, and hitting deadlines set for each iteration that has been planned. If you don't have a highly cohesive atmosphere, you can forget this methodology.

Here is a small example, that will make what I described more concrete. Let's say we have just started an agile project an agile project to create the next greatest social network ever. It's called, for those of you wondering, Social B-Free, for the hippy inside of you. Let us assume there are 10 developers on the team with 3 people in QA. If you were lucky to get that many people on your project, your good and have a great future in sales. Now that we have the people, the CEO has now set the development iterations for two weeks, since we are a fresh startup, and have a killer idea that will revolutionize the social networking industry. The only catch is, we need to get it out now, and grab some market share before someone else implements our brilliant idea. So, how do we accomplish this quickly and efficiently?

We accomplish this by setting meetings and taking a hard look at what can be accomplished in those two weeks. We define all of the features we think can be crammed into that two week time line and we stick to it. From those features, you break them down into even smaller, manageable tasks and denote them on a, list, spreadsheet, word document or some sort of wiki to keep track of it. As the CEO, he has graciously volunteered to keep track of the development lists and holds these meetings every week, keeping track of the progress of the application every day through emails, im, or whatever medium the group has decided to use. By doing this everyday for a month or two, you will become a much better predictor at what will and will not be released during those iterations. By being a better predictor, you can then start to have confidence in releasing features on a date that you specified, you could hit at the beginning, middle or the end of the iteration. By making frequent releases on time, your customers will be confident that progress is continuously being made on the application they are using. It won't become stale to them.

You may ask, what happens when we don't hit those two weeks with all the features included on the list? If that is the case, the CEO has the ability to push features to the next iteration if the CEO does not think they will be hit. There is a lot of power, and flexibility in our methodology. And by keeping at this methodology, we are getting smarter at prognosticating what the team can accomplish during those two weeks.

It's important during every iteration, to make sure everyone in the group understands the problem they chose or were assigned, every day. If there is a problem of understanding, then that problem needs attention as soon as possible. This is where having a good group dynamic comes in to play, where ideas and questions are not ridiculed and people are not criticized. Rather, ideas are encouraged, new ways of attacking problems is the norm, and finished iterations are rewarded (pizza party?). The group becomes a haven for creativity as well as ingenuity. And all while this happens, you are continuously developing solutions on the current iteration with blazing speed. The group becomes a gigantic knowledge base where no one is left behind and new people are up to speed in hours, not days.

The opposite happens when negativity enters the foray. When this happens it is inevitable that your innovation, the very heart of creating software will perish. Why? The people that are receiving negative comments are now hesitant to volunteer any of their ideas, whether it be for fear of ridicule or reprimand. The cause of not volunteering those ideas does not matter. What matters is they have now stopped giving you ideas! What if they had a good idea?! Being negative has just stifled it, along with your innovation, which is priceless to your business. Especially our really cool, hip, new social networking startup Social B-Free. We don't want this puppy to go under.

I hope I have conveyed a small portion of what agile is. I will continue the trials and tribulations of Social B-Free, very soon!

The State of Ruby

Wow. I just read the mother of all rants from this dude, Zed Shaw. He's the author of mongrel, a light web server used for ruby on rails, and from the article, he seems like a fairly competent ruby hacker. I will have to be honest though, when I read the following paragraph, I almost disregarded the entire article.

"I’ll add one more thing to the people reading this: I mean business when I say I’ll take anyone on who wants to fight me. You think you can take me, I’ll pay to rent a boxing ring and beat your fucking ass legally. Remember that I’ve studied enough martial arts to be deadly even though I’m old, and I don’t give a fuck if I kick your mother fucking ass or you kick mine. You don’t like what I’ve said, then write something in reply but fuck you if you think you’re gonna talk to me like you can hurt me."

Whoa dude, calm down tough guy. This screams like little man syndrome to me. You all know the type, they have a fuse shorter then dynamite and will try, in every conceivable way to sound like that big dog at corner of street that is always barking. Unfortunately, in reality they lack that vicious bite they try so desperately hard to make everyone believe they have. Hey, I'm not saying I hated it; quite the contrary, it thoroughly entertained me.

All jokes aside, I was rather shocked about reading some of these rants about how fractured the ruby community is. Maybe it is just this guy, I don't know. But when you read comments such as:

"Now, DHH tells me that he’s got 400 restarts a mother fucking day. That’s 1 restart about ever 4 minutes bitches. These restarts went away after I exposed bugs in the GC and Threads which Mentalguy fixed with fastthread (like a Ninja, Mentalguy is awesome)."

That is ridiculous. 400 restarts a day?! I wouldn't even deal with one a day, let alone 400! Who in their right minds would use rails if it was that gc collector was that inefficient, with out of memory exceptions being thrown left and right? I might have to take zed on that fact, however, he does know the rails core. At least he conveys that he does. I was under the impression that ruby on rails scales?! 37 Signals uses it without any problems, right?

This next interesting rant is about Michael Koziarski:

"That’s right, dude works on Rails in some capacity, apparently writing tons of shitty fucking code with his butt buddy Nicholas Sekar. Yet, nobody knows him. He’s got more web sites than Elvis and Chuck Noris combined and nobody knows him. He’s written mountains more open source code than me and no-bo-dy knows him."

Ah Napoleon, how entertaining this is to read. This is a guy I want to meet in person, dude is intense, and I like that. But to be fair to Mr. Koziarski, I hadn't known either of these two guys up until today,thanks to Zed. I mostly stay in the java/C#/spring/javascript/python world, so I never really read anything about Ruby or Rails. Now I have. Thanks Zed, you now exist in my world...for better or worse.

How bout the top 9 tips about thoughtworks processes. I think this is actually excellent material, and Zed says himself, most consulting outfits work this way. It is really hard to find a really good consulting company apparently. On with the list anyhow and take a read for yourself.

"Continue the logic further my friends with this little walk through consulting practices:

1. TW figures out it can make a mint doing RoR projects for dumb ass MBAs at dumbass companies.
2. TW goes for it and gets 60% of its business now all RoR.
3. TW realizes that they can’t hire enough Ruby people to do that. Actually, they didn’t really try too hard since that’d mean paying the new people a fair salary.
4. Yet, somehow they put 6-20 people on projects and claim that these people are Rails experts with a high standard of quality. These people actually had two weeks of training.
5. After each person has been on a project for a few months, they mysteriously get transitioned to another project, become “sick”, or generally leave.
6. They are then replaced with someone else who’s training is limited.
7. During their operations they seem to focus entirely on the process, but very little on the quality of the code. Sorry guys, but having a 1:4 code:test ratio is not focusing on code quality. It’s focusing on test quality.
8. Finally, when your project is in the dumps and it takes months to get simple things done you realize that you’ve been paying ThoughtWorks a premium for what is effectively a bunch of total newbies who are only there for a few months before they roll off.
9. You my friend got fucked in the ass. Congratulations because all the idiots who paid ThoughtWorks 6x times salary for junior ass wipes got taken and simply paid to train ThoughtWorks’ new crew."

And to prevent yourself from this consulting nightmare, some good tips. I can't argue with them, they are solid and should probably be used by anyone thinking of hiring a consulting company. Here they are:

"I have a few pieces of advice for people about to hire any company like ThoughtWorks. There’s just a few simple strategies you can follow to make sure you get the most out of them and get your money’s worth:

1. Make sure you have the right to see every resume and interview each consultant they place. Treat them like new hires and don’t let anyone who’s not worth the rate you’re paying on the team.
2. Demand a variable rate based on the position of the person and their experience.
3. Demand that no employees can leave the project to work on another project. These placements have to be for the life of the project or until the employee quits.
4. Require that you have the right to have someone replaced if they are not immediately capable. Part of what you’re paying is that a ThoughtWorker should be able to drop in commando style and just start working. The reality is they are usually totally lost anyway.
5. Seriously consider recruiting one full time employee as a team lead, another as a project manager, and then staff the rest of your team with independent consultants. You’ll find that you get more control and better quality at a lower price."

Having never been a consultant, and been sheltered from dealing with consultants at any job that I have had over the course of my career, I think every single one of those tips can save your company money. These tips allow you to keep control of the entire project, provided that you have the resources to have a watch dog hound them. However, I have rosy glasses on and I am not experienced all in this field, so please forgive my ignorance if I think these ideas are pure genius.

The rest is just more of a loaded diatribe, unless your really into that. I am not kidding when I tell you this; it's a 20 page rant, 19 of which is about trashing the same people, just in different ways. I read it, I was entertained but not worth blogging about. You can go here and check it out, and I encourage you do so. Zed made some execellent points, and deserve props for those, even though he claims throughout he has no bridges to burn because none existed. Well, with posts like these, no bridges will ever exist for you my friend, because not everyone likes your abrasiveness as much as you do.

http://www.zedshaw.com/rants/rails_is_a_ghetto.html

Just Do It!

Well it's 2008 and I am finally posting again. Gee, that took a long time, and the reason I haven't posted in a few days is the whole basis of my article. If you have something to do, just do it. Don't let it fester, just sitting there waiting for the worst thing possible to happen. You'll end up with a disaster if you do. Just get it done. I can't count the number of times that I have seen this end up as a disaster in people's lives as well as at a workplace. Missing dead lines can get you in a lot of hot water, and I am not trying to be ultra dramatic here, but it's a subject that with most people, is taboo. You just don't go there. It will most likely upset the apple cart and then you have got "dramz" and that is ALWAYS fun to deal with. But we're talking about missing a few postings here and there on a blog, so eh...

Yes, this is just a blog, and who really cares if I miss a day or two, or three, or a week. Hardy or Andrew might be depressed (Happy New Year's by the way). That is bad, but not the end of the world. However, your work ethic should carry over to whatever your doing, so here a few tips that I have come up with that I am sure are in a hundreds of self help books.

1) Don't slack.
If you can do it, just get it done. Not only will you look good, but the salesman will sell more based on your work, and the company will stand to profit from your efforts.

2) Setup a schedule at the beginning of the day.
This will help keep you on track throughout the day, and let you set some goals for you to achieve throughout the course of the day.

3) Set realistic deadlines.
Oh I am so guilty of this one. I try to bite off more then I can chew and I end up looking bad for it because I did not estimate a deadline correctly.

4) Try not to think of work on the weekends.
You can get a fresh start on Monday with a different perspective on your problem. It's good to take a break from specific problems that are starting to give you a headache.

5) Don't waste time thinking about what you could of done.
This will get you know where. Just focus on what you need to get done at the moment and just do it. You can worry about having regret later, when the dust settles.

Those are just some bullet points I was thinking about. I definitely have to work on all of those. It's not a bible, just something to try to help organize yourself and your tasks. Anyway, if you have any other points to add, leave a comment and I will add it to this list.