Posts Tagged ‘software development’
India Outsources To Mexico
Posted by: andy in Nearsourcing on April 21st, 2010
Interesting video on BPO outsourcing. I suppose that it make financial sense for them but is still seems a bit bizarre. Company in San Fran sends it’s work to India (with all of the inherent time zone, structural, cultural, and travel challenges) and they turn around and send it to Mexico (just 2 time zones ahead and 3.5 hours by plane). It seems like the extra step just compounds the problem, no?
Indian outsourcing losing ground to nearshore vendors
Posted by: andy in Nearsourcing on January 5th, 2010
Just caught this article from SiliconIndia. Looks like major Indian IT outsourcers are losing contracts to emerging rivals. They make special mention of Mexico’s Softek. This bodes well for us!
Mexican Nearsourcing a bright spot in an otherwise dismal year.
Posted by: andy in About Us, Nearsourcing on December 11th, 2009
Check out this well-written article about Mexico’s rocky 2009. The flu, recession, drug wars, rogue neutrinos - it’s been a hell of year. Thankfully, one happy little corner of the economy happens to be where we’re camped.
Another industry that has thrived in Mexico despite the recession is software development. Anchored in the city of Guadalajara and surrounding state of Jalisco, Mexican software engineers both develop their own software and provide “nearshoring” code writing services to software companies in California and elsewhere. Jalisco boasts over 200 information technology companies, and national IT organizations are projecting 11% growth for the sector in 2009 at a time when most other industries are facing contraction for the year.
Come work with us!!!
Posted by: andy in About Us, Agile and SCRUM on December 6th, 2009
We are in search of a developer to join the team here in Guadalajara. The skills that we’re looking for include: CSS, javascript, PHP, and Flex/Flash. Attitude is key in that we’ve built a really fun team and we all get along well. The candidate will have to be flexible as our development methodology (which is based on Agile) is very different from a traditional waterfall approach. We’re very picky about the projects that we do - we only do web or iphone apps that are fun, interesting, and that are pushing the boundaries of what’s possible. We’re not too hung up on university degrees or professional background. We’re looking for people who really enjoy coding and are genuinely interested in current web programming trends. If you know anyone that fits that description, please send me an email: andy@agavelab.com.
The Agave Lab Method
Posted by: andy in About Us, Agile and SCRUM on October 12th, 2009
A Nice Pair
So lately we’ve been fetching around for a way to take advantage of Pair Programming that would work for us. Some of our projects involve building relatively simple web sites. Often times, we’re building on top of a platform like Joomla, WordPress, Drupal, or Elgg, or we’re using pre-existing patterns and/or classes. In these cases, when we were pair programming, there were long periods where one of the programmers would be staring off into space while the other was installing a plug-in, fidgeting with a CSS file, or some other pedestrian bit of work. On the other hand, when we weren’t pair programming, we’d see programmers get stuck on a particularly thorny bit of code, architect themselves into a box, or miss a critical shortcut.
.
What to do? Pair programming seemed like overkill but without it, we were often spinning our wheels. Enter the “Agave Lab Method”. Here’s how it works:
- Programmers work in pairs.
- Each pair is given two projects.
- Every morning, the pair spends 3 hours together, with 1.5 hours dedicated to each project
- After the 3 hours in the morning, each programmer works on a project solo for the rest of the day
- The next day, the same thing happens EXCEPT, after the three hours working together, the programmers switch projects.
- So, for example, on Monday programmer 1 works on project A while programmer 2 works on project B. On Tuesday programmer 1 works on project B and programmer 2 works on project A. On Wednesday, we switch back.
Okay, I know that this sounds weird and complicated but stay with me here. Every morning, programmer A has to explain to programmer B what he/she did the day before so that he/she can pick up from where things were left off. In addition, each programmer needs to plan out, with the help of his/her partner, what he/she intends to accomplish that day. This forces the right things to happen:
- It forces the code into intelligible form. If you know that someone else is going to pick up where you left off, your code has to be clean, logical, and well-documented
- Two heads are better than one. Solutions are first architected (and later reviewed) with input from two people - this leads to more elegant code.
- A set of fresh eyes can spot potential bugs, and offer suggestions on how to re-factor cumbersome elements
- Knowledge transfer is maximized
- Boredom / burnout is diminished
- Programmers get better at verbally communicating what they’re doing, why, and where they’re having problems
- If there is a particularly thorny bit of code, the pair can co-program during the 1.5 hours of shared time, leaving the more understood programming tasks for solo time in the afternoon.
Of course all of these benefits flow from standard pair programming and, for more complicated projects, we’ll still do full-time pair programming. However, by using this modified approach, we get more throughput (progress on 2 projects rather than 1) and less staring-at-the-wall time for those projects that involve a lot of straight-forward implementation.
The Sound of the Other Shoe Falling
Posted by: andy in Things That Interest on April 9th, 2009
From an article entitled Tech jobs getting zapped, “Year to date, 8,000 tech jobs have been slashed, including 4,100 just last month.”
I’m not sure if this is good for us or bad for us. The recession has forced plenty of early-stage tech companies to find ways to do more with a lot less (aka: good for us) but there will be plenty of laid-off tech workers that will be willing/required to work for less (aka: competition, aka bad). I guess we’ll see.