Sunday, October 31, 2010

Distributed Development / Divorced Software Development

In an attempt to dispel the level of optimism in distributed teams: I'd like to negatively state that divorcing your team like this is the worst way to achieve team efficiency and sustain a high level of quality in your products. None the less, it still happens project to project. I've bounced back and forth between teams where we've stuck in pods (all in one common area) and some where I'm dealing with teammates in a different continent. Sadly, most of the projects that have somehow dwindled down the path of hiring cross continent resources have been the most stressful.

It's not the people that cause problems. As a matter of fact, the team is usually composed of wonderfully talented and smart people -- It's the ineffective communication channels that get incorporated into the delivery process that ultimately divorces team/client expectations.

My primary concern about distributed teams is that upper management fails to see the overall picture of software delivery. Developing software that will indubitably be shipped out to users is not like building toys and shipping it out to kids. Software isn't' built in factories--it's an evolutionary product that empowers your users. Furthermore, there is this imagery that is seeded into the minds of upper management of a programmer building doorknobs (components) that go into doors (web application) and get put into houses (infrastructure/platform). Negatively, we face these issues because of upper management's idea of "how software is shipped to real world users" is hazed and often imagined as a crew of factory workers in a line creating door knobs. On the whole, this stigma isn't exactly targeted to just programmers but to anyone on the production team, such as, designers and quality assurance.

In order to build great software for your users, your team should have a realistic picture and shared vision of how their loyal customers are going to use it. Distributed development--I mean, divorced development not only blinds some of your team members but painfully discourages any sort of effective participation to improve the product. If you hired a programmer from China when your team is in New York, suddenly, he thinks of a great idea of how to make a particular feature more convenient to the user, how is he supposed to communicate this to the team? He has several ineffective ways:

1) Email (which everyone can easily ignore)
2) Calling into scrums/meetings (which is completely useless if people don't document it)
3) Phone call to the lead developer (which everyone can easily ignore as well)

I'm not bashing the fact that the developer is from another part of the world--I am bashing companies with an upper management that enforces such ridiculous team compositions that essentially paralyzes your ability to build great products. I feel sorry for teammates that are far from the core team (design, development, and quality assurance) when they want to participate in the improvement of their delivery but can't due to their proximity and the limiting factors that snare their ability to communicate effectively. Ultimately, team compositions using distributed development practices encourages and amplifies corporate learning disabilities, such as:

1) I Am My Position
2) The Enemy Is Out There

Business has always been about relationships and communication. Indeed, your company can save millions of dollars in development by outsourcing but if you do decide to use this software delivery strategy, then keep constantly inspecting the level of quality in your product line. Upper management will always have a level of blindness to the quality of their product and will always see how much upfront costs they can save if they indoctrinate distributed development processes. If your management team doesn't know how to use the product that you're trying to build, they will never really have the sense of how great the product is for their users as a human being.



Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, and Cox Communications. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Wednesday, October 27, 2010

What If

Have you ever asked yourself "what if" when you reach a point in your life where you could've acted on an opportunity? I've been an evangelist of the following quote: "you miss 100% of your shots you don't take". After having this ingrained in my mind for so long, I've come to realize that I am almost always disappointed with myself. Every opportunity I take advantage of, I'm always disappointed--It's like I constantly become blinded: I look at the situation negatively and see how I could've done things better. I feel like a plethora of opportunities lead to an infinite loop of disappointments.

Do I need to dispel my blindness and take the time to cherish the small victories in life? or learn to let things go when mistakes happen? Do I need to stop consistently blaming myself for anything that goes wrong in life? Do I need to sink back down to reality and accept the fact that "I can't always be the hero"?

An endless list of conundrums.

I've always been an independent person with full confidence in my ability to get things done. I put an endless amount of faith in my teammates and I'm righteous about "if you're unhappy, it's because you let yourself become unhappy". Even after so many disappointments, I feel like it's my duty in life to hold on to my humanized values, intuitive sense of honesty, and truthfulness.


Regards,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, Cox Communications and Microsoft. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Tuesday, October 26, 2010

Mentors

In my life quest to figure out the deeper arcanes of social dynamics and emotional intelligence--I've taken notes on patterns of behaviour and characteristics in most great leaders of our time. Frequently, I hear the phrase, "person of integrity" being used to describe leaders.

What does it mean to be a person of integrity?

Wikipedia has the following definition:

Integrity is a concept of consistency of actions, values, methods, measures, principles, expectations and outcomes. In western ethics, integrity is regarded as the quality of having an intuitive sense of honesty and truthfulness in regard to the motivations for one's actions.

Reflecting on my own career--I've been very fortunate to have been led by great individuals that exhibit the level of integrity that Wikipedia describes. In all honesty, my leaders have always been great mentors: they've taught me how to react to situations, how to be as technical as I am today, and how to communicate effectively with other disciplines on my teams. Without such amazing and disciplined mentors, I wouldn't be where I am today and I'm extremely grateful for that.

Mentors don't exactly need to show exactly how certain technical things can be done. Mentors essentially setup a mental framework to create a disciplined thinker. For example, Freddy Roach is Manny Pacquiao's mentor and boxing coach. Freddy certainly can't box at the technical level that Manny can; however, Freddy Roach setups a disciplined approach to thinking: hard work, dedication, sacrifice and most of all "never giving up". By ensuring that Manny's mind is mentally conditioned, he is able to push himself beyond any human limits and be the champion he truly is (best pound for pound fighter in 7 different weight divisions).

Day by day, I constantly strive to push myself beyond my boundaries: learning new things, putting strategies to practice, and improving team vision/learning. Core characteristics, such as, integrity, dedication, courage, never giving up, and sacrifice are all things that I've inherited from my mentors.

In the future, I will achieve my life goal: to be a disciplined mentor for my own teammates just like the heroes that mentored me in the past and perhaps one day I can hopefully make them proud.

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, Cox Communications and Microsoft. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Saturday, October 23, 2010

Adding and deleting git tags

Adding a git tag

Common Case:

Johnny is the developer on a project that is about to go-live. Their codebase has passed all unit tests and functional/behavioural tests from QA. Before going live, he needs to tag the current revision so that his whole team can easily backtrack and possibly fix any last minute bugs before launch but also make it so that his team can also keep pushing code to the master branch.

Create the tag:
$ git tag -a v1.0.0 -m "2010-10-10 Production-Ready"

Double check which tag was created:
$ git describe --tags

Push tags to your repository
$ git push --tags

Deleting a git tag

Common Case:

Johnny accidentally created a tag called "v1.9.0" instead of "v1.0.0". He needs to simply delete this tag so it doesn't confuse other developers.

Delete the tag
$ git tag -d v1.9.0
Push the deletion of the tag to your repository
$ git push origin :refs/tags/v1.9.0


Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, Cox Communications and Microsoft. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Thursday, October 21, 2010

Why We Still Need Heroes

History has proven time and time again that the world needs heroes. People who are helpful, selfless and dedicate themselves to a cause--a high level initiative. In the realm of software delivery, where you have to ship a product on a tight deadline, you often face burnouts and frustrations--a seemingly impossible uphill battle. That's why you call on your heroes...

Horatio Hornblower was a British admiral full of integrity, courage, and intelligence. He fully understood the potential and limitations of his team. Without any hesitation, he answered Britain's heroic calling to engage Napoleon head on.

While waiting at his Mediterranean rendezvous point for the rest of his squadron—and its commander—to arrive, he carries out a series of raids against the French along the south coast of Spain. He learns that a French squadron of four ships of the line is loose, having slipped the blockade. He decides that his duty requires that he fight at one-to-four odds to prevent them from entering a well-protected harbour.
- "Horatio Hornblower" Wikipedia

When heroes answer the call of duty, they are compelled to go into battle with the odds stacked against them. His crew had a choice of evacuating back to England but they followed him into battle because Horatio led them: Horatio knew how to encourage his teammates--Horatio knew how to empower his teammates--Horatio could dispel the fear in his crew and transform them into valorous soldiers by crystallizing a shared vision.

In our current projects, we face the same types of situations--sometimes you're thrown into a situation where you can make a difference. In more recent times, Bob Fitch is Blizzard Entertainment's lead programmer. When everyone hated the original Starcraft because it looked like a reskin of Warcraft II, he completely rewrote the game engine within a short period of time. People loved the new result. Starcraft went on to become the most popular eSport in South Korea. South Korea has 2-3 full time running eSports channels dedicated to Starcraft alone.

If you have a lead with that level of integrity, righteousness, courage, and dedication--more people will start to follow in their footsteps. Generally, they want to change the scene and improve things for the better. Furthermore, Blizzard Entertainment has a proven track record because they are a legion of heroes.

Software companies of today never really encourage their "resources" (a foul word for a person working at an agency) to break through walls and voice out their opinions. Incidentally, corporate software development is paralyzed with the learning disability known as "I AM MY POSITION".

You have the ability to punch through walls--you just don't know it until you've tried it. Your actions shape you and your team's reality--you're important to the team. Fill multiple roles (break out of your position), change things to improve your team's shared vision, and eventually, you'll be the hero.

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, Cox Communications and Microsoft. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Sunday, October 10, 2010

Understanding Your Team

Have you ever been put on a team that is so brilliant and talented and somehow the project is frustrating to deliver? I've come to realize that when working with a team of great people, there needs to be a level of transparency and level of understanding of what we're trying to build as a whole. In the agency realm, typically you'll have 4 disciplines working together to ship a website:

1) Design (Creative)
2) Development (Frontend and backend)
3) Client Services (Project manager)
4) Quality Assurance

My evolved thinking has brought me to the conclusion that there can't be such a thing as blame. Understanding the delivery as a whole will help dispel the shackles of each discipline. Furthermore, each member of a discipline should fully understand how much of an impact their decisions will make on another part of the system. For example, a designer can choose to break consistency by readjusting the website's grid on a particular page. This would have a negative impact on the development team as most of the time grids are set up at the start and they stay consistent throughout the whole website (column widths). That said, it isn't the designer's fault at all--he/she was just doing their job with poorly written requirements. It could've been that the developers didn't voice that out to the designer--that they're pretty much married to a specific grid format.

Another example is how client services could oversell on a feature that could mean 12hours of design work and 40 hours of development effort. If the client services person knew about how much damage that would cause to the timeline, he/she wouldn't have proposed it to the client. As another example, typically technology platforms for websites can't react quickly to client feedback or design changes. We have very simple tools nowadays to help speed up the approval process from clients, such as, Adobe Photoshop; however, since we ultimately need to ship a website as a whole, even if one part of the system speeds up, the platform itself takes time to catch up. This is called backlog.

Working together doesn't just mean sitting together, or joining scrums--It means learning together. If we learn from each other, learn about our disciplines, learn how each discipline affects another, we can be far more efficient because we'll fully understand our own limitations as a team.

Ultimately, much like the beer game, the problem isn't the process or the system...it is actually "us". We fail to understand each other and how each of our disciplines can have a negative impact on each other based on the decisions we make.

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, Cox Communications and Microsoft. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Monday, October 4, 2010

Random Thought at 1am: Treating People Like Human Beings

I've changed a lot since I came out of post secondary.

When I first came out of post secondary (BCIT), I was a driven, dedicated, and passionate knowledge-hungry kid that wanted to tackle each and every challenge on my path to glory. After developing my technical skills, I solidified myself as a maven for writing great code and building great software. Negatively, on my career path, I came across many different people that end up not treating me for who I am. In my past, I've been often labeled as a "kid" or "inexperienced codemonkey" in the workplace. I believe that if someone wants to label me as that then they can--it's completely their opinion; however, someone shouldn't be completely ignoring my technical opinion because of the limited number of years I've been programming--That's ageism.

One thing that holds true about technology and design is that everything changes so fast. "Highly experienced developers" can legitimately be kids out of school nowadays because of how fast they learn new technologies and leapfrog over pitfalls. "Experience" is questionable now.

Conversely, in other industries, you can compare a carpenter with 40 years of experience to an apprentice carpenter--The difference is huge. If you compare a JavaScript developer with 20 years of experience to a Computer Science graduate--what can you honestly make out of this? 20 years ago, no one used JavaScript to create stunning animations, highly scalable network programs (NodeJS), or amazingly responsive interfaces. So why does technical experience matter? Results should matter. Does the person know how to "get things done"?

Even though I've run into these situations where I am a victim in some way of ageism, I reflect on these experiences and ultimately those experiences have made me a battle-hardened, better person. For a while now, I hold true to this: I am a person of integrity, maturity, and technical ability with a tad bit of facetiousness to break tense situations. You can take shots at me all you want but at the end of the day, I'll still treat you like a human being. Following this mantra has done wonders for me in terms of career, quality of life, and social life.

There are several people in my workplace that exemplify this heroic persona--you know who are. You guys are the real heroes.

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, Cox Communications and Microsoft. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.