I once had a consulting gig where I was one of many distributed developers on the team. We had weekly scrum meetings over Skype/WebEx from 4 different time zones. These meetings usually ended up taking at least an hour.
Scrum is all about being agile. Hour long meetings are not agile.
When you have a distributed team that is larger than 5 members it can become difficult to manage. The key is to meet with a team of developers in small blocks. Schedule a meeting with the API guys at 9:00AM then a meeting with the front-end team at 9:15AM and so on. There is no need in gathering people that aren’t required in the meeting to sit idle. Let’s get real, they’re going to be chatting on IM, reading the news, or brewing up a pot of coffee.
Your job as a manager is to make sure each team is executing. Execute on multiple threads, I say.
New iPad (3rd generation).
Pros:
- Awesome screen. Better than your HDTV. Seriously.
Cons:
- Heavier than iPad 2
- Less battery life than iPad 2
- Slightly thicker than iPad 2
Upgrade if you have an iPad 1/any Android tablet/are a developer/are a fanboi.
When the iPhone 4S launched, Siri was the bee’s knee’s. I’ll admit, I was one of those customers who spent all night asking Siri asinine questions like how much wood can a woodchuck chuck if a would chuck could chuck would. Siri was the ultimate party trick. Then the novelty wore off and I stopped asking it stupid questions.
Here is how I use Siri now:
- Setting reminders while I drive
- Setting calendar appointments while I drive
- Setting my alarm before I go to bed
- Getting driving directions, while I drive
I don’t ask it for the weather, or stock prices because its faster for me to just launch those apps. Siri is great for complicated, multi-step tasks, especially when you need to be hands free.
Because I’m so dependent on Siri I pretty much need to have Reminders, iCal, Maps, and Clock or else my entire GTD workflow is done for.
This makes me wonder how much tighter integration will get once Mountain Lion is out and we get these iOS apps right on our Mac’s?
Siri is here to stay.
There have been numerous blogs, advice, and studies on how to hire developers for your startup. It’s the single most important role for founders, CEO’s and CTO’s of a software company. The 2011 trend seems to favor hiring:
- Hackers who can get shit done and willing to learn anything
- Coders who are also secretly designers
- Coders who can move up and down the stack (front-end to back-end)
During the interview people like to evaluate:
- Portfolio > Resume/Corporate Experience
- Puzzles/Engineering Challenges
- Familiarity with languages/tools/software engineering practices
This is all great, and very helpful in determining great candidates. However, in my opinion the single most valuable criteria to determine is how well a developer can debug. The majority of time spent writing software is actually fixing bugs.
I want to know:
- What is your debugging process? Do you use debugging tools?
- Do you write test cases? How many? When is it overkill?
- Do you prioritize bugs over features? When?
- How do you communicate defects to customers or product management?
Fortunately we are living through a time where there are great hackers among us. Everyone is more than capable for being a candidate at your company. As an executive, it is your job to find the best ones. The best developers are the ones who don’t introduce bugs into the codebase, and can help eliminate bugs that exist.
We all learn in project management/engineering 101 that feature creep is the number one reason for why 99% of software projects are always delivered late. While this is true, and incredibly damaging to not only profits, but team morale, this is often attributed as the sole reason for why projects fail.
Time to shed a bit of truth.
Defects hurt your product more than overcommitting to your customer. Prioritizing new features over existing bugs won’t make your app shinier. You can brush bugs under the carpet for a while, but its only a matter of time they come back out as your software gets larger. As new lines of code are added, new paths to revealing your bugs are exposed.
In theory everybody wants a 100% bug-free product, and it’s easy to say “fix that bug and then move on”, but fixing bugs has an engineering cost. Defects typically take longer to debug and don’t add any business value to the customer. It is a behind the scenes skunkworks operation that gets no recognition.
In a perfect world, we would rally the development team and assign all bugs for the current software iteration and have the QA team on-call to make sure the bugs get tested in every scenario, while product management pushes back new features to the next software iteration (this can be weeks).
Yeah right. The world isn’t linear. There is no right approach but I typically stick to a few rules:
- QA should log all bugs with reproduction steps and stacktraces in a defect backlog for the tech/product team to prioritize. It’s extremely important to include reproduction steps and a stacktrace as it will save debugging time, which is engineering time, which is costly time.
- Bugs that will impact the customer over 50% of the time are showstoppers and must be addressed immediately in the current software iteration. No new feature will help you gloss up your app when a showstopper bug is apparent. Fix that shit.
- One day of the week should be dedicated strictly to fixing bugs. This will stop bugs from piling up and keep the software integrity in tact.
- Celebrate being 100% defect free because it won’t be long until new bugs get introduced into your software. Enjoy being 100% bug free as a team. Development/QA/Product teams are polar opposites of each other. While we all work together, things can get rough during crunch time, and celebrating common success is a great team building activity.
I’ve attended my fair share of meetings throughout my career. Code review meetings, feature planning meetings, scrum meetings, client meetings, urgent life-stopping bugs being reported meetings (to the customer the world must stop :).
Meetings are highly disruptive. People are most productive when they’re in the zone and uninterrupted. Meetings disrupt this workflow, and going back to a productive state often requires more time, and in that time another meeting can get scheduled adding toxicity to the rest of your day.
I have a rule. I only schedule meetings from 8AM-12PM. This serves a few purposes:
- Blocking all meetings together does not disrupt actual productivity.
- The brain needs to wake up and get going before getting into the zone. A morning full of meetings, with jabbering clients/customers is a great remedy.
- Eating lunch after a morning full of meetings prepares the body with the sustenance to get into the zone and get shit done.
Meetings are important. A killer project without communication is a recipe for failure. So here are some tech tips for scheduling meetings well.
- Always send out an invite. This eliminates e-mail/confirmation overhead. Asking your client if “we’re still on” is a waste of time when tools like Google Calendar or Microsoft Outlook can automate that for you.
- Use a headset to take calls. This frees you to take notes on your computer. I like to use Google Docs or Evernote so my notes are stored in the cloud and accessible from any laptop or my iPhone.
- Send screenshots or videos beforehand if you are doing a demo. This might kill the element of surprise, but if you’re doing a demo over the phone, you’re either doing it wrong, or its not that important.
After meetings are over the rest of the day is yours. Use it wisely.
Files are going to be a thing of the past. Gone are the days of creating folders, shortcuts and managing your recycle bin (lolwut). Managing files is cumbersome. Most people are also notoriously bad at staying organized.
This is why Gmail doesn’t have folders for your inbox. If you want to find an e-mail just search for it. Let Google take care of it for you.
This is why the iTunes App Store manages all of your apps on your iPhone. So you don’t have to worry about installing and removing them.
As we move into the “post-pc” world dominated by our mobile phones and tablets we won’t be managing files anymore. We are going to be using our apps.
This is a huge shift in how we will use our computers. Instead of thinking about where your files are, you are going to think about which app you’re going to use.
This is because all of your files will be stored in the cloud. It doesn’t matter where they are. Your app will know and take care of it for you. This is seamless. This is bliss. This is exactly what iCloud is trying to achieve.
