June 4th, 2011 § § permalink
I recently came from a small startup company in Houston where process was non-existent to a significantly large bank where process is king. After speaking with an ex-coworker, I came to an interesting reflection of the two ends of the spectrum. On one end, getting things done was an open field where you could choose etch your own path and very easily gets lost in all the choices. On the other end, getting things done was a pre-paved road with traffic lights, construction sites, and stop signs that get in the way of a predetermined destination. No matter what, my goal was to get to each of the checkpoints and hopefully have a successful deliverable. There has to be a happy medium, but I haven’t found that yet and would love to experience it.
My First “Third”
After four months in my new role, I’m finally working toward a release I understand and have a handle of the architecture and design of the application. I really can’t say much about the details of my job, but I create software for a part of the business of a fund of funds, in particular hedge funds. The business of a hedge fund has caught my attention, but unfortunately I’m not challenged on the technical side as I would like. The challenges touch many aspects of Michael Feathers’ book, Working Effectively with Legacy Code and I have been slowly trying to introduce unit tests to the team. Being a team lead here is definitely a challenging experience when the software and processes are already in place and the people are uncomfortably settled with them.
Wait, so what is a hedge fund? I’ll let the Khan Academy tell you the basics, it’s great!
There are other types of fund strategies that blow my mind. I’m not going to (I actually am not allowed to) get into any stories or details of what some fund managers do, but they really know how to find
loopholes opportunities to make a dollar or two or billions, yes with a “B,” for themselves and their investors.
Teaching and guiding the team about best practices keeps me going and even pushed me purchase my first Android app, Read It Later, since there is absolutely ZERO service in the subways! Below are some things I have shared with the team and maybe they’ll interest you. If you’re not a software developer or have no interest in making your code awesome, you have permission to leave.
Derek Greer’s ongoing series on Effective Tests
This is perfect for Unit Test newbs and helps answer, a lot of the “whys.” Often times I get feedback about how long it takes to implement unit tests, but the return is ridonkulous. Unit tests do way more than just exercise your code – by making your code testable, it helps make it way more flexible, contain less dependency, and most of all: awesome.
Want more? Just subscribe to the Los Techie’s blog
Some GoogleTechTalks Videos on Unit Testing
If you hate reading, check out some videos from GoogleTechTalks.
“The Clean Code Talks — Unit Testing”
“The Clean Code Talks — Inheritance, Polymorphism, & Testing”
My Goal for This Month
After speaking with my colleague, about improving myself at work, I’m going to try out Pomodoro here at the bank. I’ll use KeepFocused and hopefully I’ll be able to determine where my inefficiencies are from week to week.
January 1st, 2011 § § permalink
I had a conversation a while back with a good old friend, Sonal, about how awesome Modern Family is and catching up with each other’s lives. It sparked a reason for me to share something that has been on my mind for quite some time, but could not figure out how to organize my thoughts. With a little discussion with her and some time to
sound type out my thoughts, here is the breakdown:
- Learning when to say, “no”
- Learning how to say, “no”
- Learning how to get them to say, “no,” even before you do
Over the past six months, I’ve been learning a lot about setting the right expectations within the development team, with coworkers, and how it affects our customers.
The Dark Past
As discussed in my previous post, we weren’t (until recently) in a position to make decisions to have a positive impact in our daily development lives. We knew about the “fire-of-the-day” that we had to take care of while interrupting our current work and just had to buffer enough time to make sure we got things done in time and sacrificing quality. Readjusting the project plan, timelines, priorities, and resources wasn’t a part of our process.
Something had to change.
1. Learning when to say, “no”
I can’t remember the exact moment I started saying no, but can remember an incident that kind of shocked a coworker who wanted something done. It wasn’t because I didn’t want to work on it, I just had way too many other things on my plate and over-promising would end up burning me out or under-delivering. I just kept it simple and said, “no.”
2. Learning how to say, “no”
Saying “no” is kind of rough and a little pessimistic, so I’ve learned to defer work. There was a request to fix the Partner listing because one of the descriptions is wrong. The application based the list on an Excel sheet I was provided, so the only way it could be wrong is if someone gave me wrong information to display. It wouldn’t take long, but it would interrupt my current stream of thought if I worked on it immediately. I put the request in a list for me to do later.
I really didn’t say no directly, but I did learn that I could say no for the moment and defer the work to do later. Rather than dropping everything to put out the fire, I just made sure we were all aware of the other issues at hand and I would get to it later.
3. Learning how to get them to say, “no,” even before you do
There are two ways I’ve been able to do this. First, is to get you to prove to upper management that your task is more important that what I have to work on. The second way is for me to just point to my Kanban board and ask where the trade off can most effectively ensure no interruption to a previously promised delivery.
Usually the fire-of-the-day task isn’t important enough to bother upper management with the question, so they’re happy with just creating a ticket, assigning to me, and holding the responsibility of bringing up the task at the next iteration meeting.
Now, most of the time, I’m approached not whether to decided if a task can be done, but instead if the ticket someone created makes enough sense for me to look at later on. That is ultimately amazing!
A Brighter Today
There has been a complete 180 from what we were earlier this year and today. Significant enough that people open to change and progressive ideas like Jason Fried‘s no-talk-Thursdays (our are Tuesday and Thursday 8am-11am) which makes our development team very productive which and in the end it helps keeps the Sales/Marketing team honest.
The best part about making sure everyone is on the same page is the positive impact on customers. It gives potential/current customers a good time frame for features/bugs to be delivered and our close partners a good time frame for future products not yet on the market.
September 12th, 2010 § § permalink
Just over one year ago, we released Security Auditing SP2. In the last few months of 2009, we were bug fixing and preparing a new product line to present at Microsoft Management Summit 2010. We were at a turning point for development and had a new direction to introduce a structured and formalized processes to help ensure a solid product delivery.
After a series of releases with this structured and formalized process, I’ve learned a lot of things that were quite obvious many other software development shops – I’ve read about them on many blogs and at ALT.NET events. The hardest part about software development isn’t the coding or testing. It’s finding the right process that fits not just the development team, but the entire company as a whole. From Sales and Marketing to Customer Support and all the way up to reporting to the investors, there has to be a good team chemistry.
I’ll highlight a couple things I’ve learned and things that I’m hoping to change in order to make sure we can attain a better team chemistry in the upcoming months and hopefully start 2011.
The Right Communication
No communication is bad and when you’re working in silos it’s unbelievably horrible. Even worse is when everyone has their own “order of importance for communication.” Here is mine:
- Face to face
- Yelling across the hall
- Instant Message
- Phone call
- Voice Message
- Snail Mail
Oddly enough, this order also reflects my “response time”. The more crap you put between the communication, the longer you’d better expect to wait for a response from me. Telepathy is just something I’ve learned to ignore, hehe.
Lesson learned? The best communication is an open communication. Sharing what was agreed upon with other key players is the best way to ensure understanding and maintain accountability.
Lack-of and Over Documentation
When I first started at Secure Vantage, I knew nothing about the requirements for documentation. I just happily went along developing what was asked for me to create and relied on myself for unit testing. It was great since the person QA testing my products sat literally next to me and gave me feedback pretty much immediately. The problem with this is solely due to lack of accounting for my hours and time dedicated to the project. It can be seen as a good thing or bad thing. It was all based on trust, honesty, and openness.
In Q3 of 2009, some changes in staff and management moved in the direction of a less flexible and more structured development process. The first problem we ran into that completely overwhelmed the team was documentation – something we’re all unfamiliar with, but still expected to deliver.
- Change Request Form
- Requirements Intake Document
- User Requirements
- Product Definition Document
- Data Analysis Document
- Technical Analysis Document
- High Level Solutions Document
- Cost Estimate Worksheet
- Risk Analysis Matrix
- Quality Assurance Plan
- System Infrastructure Requirements
- Software Requirements Specifications
- Interface Requirements Specification
- Performance Requirements Specifications
- Data Development Document
- Software Development Plan
- Marketing Communications Rollout Plan
- Testing Plan Checklist
- User Manuals
- Project Assurance Signoff Letter
- Change Log
- Release Notes
- Equipment Installation Plan
- Deployment Rollout Plan
- Support Plan
Realistically, all these mean nothing if they aren’t discussed and reviewed. It’s great to present this list as something to do, but it is completely pointless if no one takes leadership and ownership of this ginormous list. It’s even worse if the person responsible for them delegates them without reviewing them once they’re done. After the first couple documents I created, it seemed like what I delivered was useless. It was quite frustrating – no one likes making something no one uses.
Looking back, I probably could have stood up and took ownership of these documents, but instead I was tasked to take more of a development lead role and left the documentation responsibilities in the back burner until someone actually reviewed documents I created. Bad idea.
Lesson learned? If you see something wrong, don’t just push back and question it, change it. I failed to change something I saw was wrong despite how much I voiced my opinions.
Meetings Meetings Meetings
First of all, I hate meetings. It’s not the concept of a meeting that I hate, it’s how most people make them: “Weekly Monday Meetings”, “Weekly Status Report Meeting”. I don’t believe in creating a meeting based on a recurring time unless each and every meeting has a proper agenda. Whether it’s a checklist of tasks, a document, an agreement on a decision, or even just a meeting to make sure everyone reviews and agrees on a priority list of work items that will go into the next release, they all have a resulting deliverable.
Holding a productive meeting is hard when one of the ten topics goes on a tangent or when you waste 10 minutes waiting for everyone to join because they haven’t installed the GoToMeeting software on a new machine. Sometimes pushing off side topics for another discussion is necessary to ensure the current list of topics isn’t forgotten. It prevents the meeting from lasting, what feels like, FOREVER.
Here is my recent favorite article on meetings: How to Run a Meeting, by Rands in Repose.
Lesson learned? If there isn’t an agenda for a meeting that you’re required to attend, ask for one when it starts. It will help prevent it from getting sidetracked and in some cases you’ll find there isn’t one. If this is the case, you’ll be able to go back to getting shit done instead of just talking about it.
Things aren’t going quite as I wanted or expected, so you might ask me why am I still here? (A lot of my friends have.) It’s plain and simple – I’ve changed my mentality from, “follow the rules, hierarchy, and follow the more experienced” to “I don’t give a fuck, I’m going to do what I think is right unless you can prove me wrong.” Cocky huh? Yeah, I admit, it’s pretty ballsy and out of my character, but I can’t just sit around and watch it fall apart.
I wouldn’t say it’s a rebellious move, but instead a determination to help make the Development Team’s environment better and later down the road a better company as a whole. I’m hoping to not just learn from the experienced colleagues, but also teach them some new tricks.
It’s been a couple months now since I’ve had this mentality and I can confidently say that here at SVT, we’re getting much better – proper communication, just enough documentation, and productive meetings. It hasn’t just reflected in the Development Team alone, but with the Sales Team and Customer Support Team too. Everyone, including our CEO, has seen such a drastic and positive change, YAY!
We’re currently winding down our first really successful iteration and things are going really great! I’m finding myself looking forward to going to work again, excited to see what we can accomplish at each day’s end.
The one big thing for us to fix is the epic battle between creating new products and features versus maintaining our old ones with limited development resources. If it were my choice, I’d follow The Joel Test for being a successful software team: fix bugs first.
June 29th, 2010 § § permalink
To manage our virtual machines we use Virtual Machine Manager 2008 R2.
I have trouble logging into my VM after doing just a couple reverts to checkpoints. The machine drops trusts to the domain, so it won’t let me log in with my domain account, boo.
Here’s how to avoid it. Thanks, Kevin.
For these steps, log in with a local administrator account:
Set the registry key below:
HKEY_LOCAL_MACHINES\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters DisablePasswordChange REG_DWORD 1
(Reboot and add new Checkpoint A)
Rejoin the domain
(Reboot and add new Checkpoint B)
Run all the important Windows Updates
(Reboot and add Checkpoint C)
Step 4: Remove Checkpoints A and B
(I hate patching virtual machines…)
March 2nd, 2010 § § permalink
I found out how close we really were from the IRS building that was hit by a plane. I was first surprised to find out that the hotel we stayed at was right across the street from it. The thing that surprised me most was the location of the event itself – just across the parking lot!
Although my coworker and I left Saturday night to go back to Houston, the sessions I attended in Saturday were, as always, really interesting. I’m going to try and regurjitate what I have in my memory from the weekend. I’m going to review Sunday’s sessions to see what I missed.
Overcoming resistance to Adoption of Agile methods
The more important problem here isn’t actually selling Agile methods, but instead how to sell it. There seems to be a huge language disconnect between software developers and their (non-technical) managers. Software-development-English is really different than business-English. One way to bridge this gap is to start learning about seeing things in another point of view. In my case, I need to learn about how to explain problems and solutions in such a way that it impacts revenue, profits, and basically the bottom line.
Books mentioned: Release It! | Ship It!
What does it mean to be a software architect in an iterative world
As some of you may know I’ve been promoted to Senior Software Architect. Honestly, I had no idea what an Architect is or does, so transitioning into this role was something I was determined to find out. People in the session collectively put it best:
Architects are responsible for putting that dot on the horizon and guiding/zig-zagging the current software project(s) there like a sailboat.
So the goal is to iteratively make changes of the zig-zagging to make sure we don’t stray too far from that dot on the horizon since that is also a moving target.
Books mentioned: The 5th Discipline and Fieldbook | Enterprise Architecture as a Corporate Strategy
Open the Kimono
Although I’m not a web developer, I went to see what Jimmy Bogard had to show off. He’s a really sharp guy and definitely has some things to show from his project.
Branch/Release per feature
Basically, branch per feature is something that Martin Fowler is against since it allows for the merge points to become difficult and painful the longer the points are from each other. Despite this problem, the argument for this is that it allows for half-completed features to be excluded from the release of fully-completed features. Martin Fowler definitely has a valid point, but by making features small and iterations short, managing the merge points will definitely be less painful.
Discriminated Unions explained with poker. I’m going to start a Project Euler repository with F# solutions, but we’ll see how far I really get.
Books Mentioned: Real-World Functional Programming with examples in F# and C# | F# Wikibooks