1. Learning when to say, “no”
2. Learning how to say, “no”
3. 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.

Saying, “NO”

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.

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:

1. Face to face
2. Yelling across the hall
3. Instant Message
4. Phone call
5. E-Mail
6. Voice Message
7. Snail Mail
8. Telepathy

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.

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.

Step 1

Set the registry key below:
HKEY_LOCAL_MACHINES\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters DisablePasswordChange REG_DWORD 1
(Reboot and add new Checkpoint A)

Step 2

Rejoin the domain
(Reboot and add new Checkpoint B)

Step 3

Run all the important Windows Updates
(Reboot and add Checkpoint C)

Step 4: Remove Checkpoints A and B

(I hate patching virtual machines…)

“What Agile really means to the future of software development“
Martin will call upon his more than 20 years of software industry experience to talk about how the history of the software also serves as a roadmap for what to expect in the future.

Martin had three very drastically different mini talks rather than a single long presentation. I really liked this approach since it helped keep my short attention span.

I. Continuous Integration and Continuous Deployment
His presentation comparing Feature Branching and Continuous Integration was just a regurjitation from his older articles, discussions from other presenters at other events, and a book he recommended by Paul M. Duvall. I won’t bore you with it.

Something that caught my eye was Continuous Deployment and what he called the “build pipeline.” He had an awesome flowchart/diagram to explain this, but I’ll try and do it with a list. I’ll include the tools I currently use in our development environment at work, if they apply.

• Commit Task – usually kicks off a full build of the main stream on a build server, not a local machine
  • Compile: Visual Studio
  • Tests: NUnit
  • Assemble: NAnt
  • Code Analysis: NCover and FxCop
• Artifact Repository – this can be a file share to maintain each build version from the Commit task above
  • Binaries: CruiseControl.NET
  • Reports: NUnit, NCover, and FxCop
  • Metadata: I have no idea what this is, any ideas?
• Acceptance Task – of a specific version in the Artifact Repository
  • Configure Environment
  • Deploy Binaries
  • Smoke Test
  • Acceptance Tests (customer focused)
• Performance Task – of a specific version in the Artifact Repository
  • Configure Environment
  • Deploy Binaries
  • Smoke Test
  • Performance Tests
• Deploy Task – of a specific version in the Artifact Repository
  • Configure Environment
  • Deploy Binaries
  • Smoke Test
  • Run

I’ve got the Commit Task and Artifact Repository down to a science at my job and it’s a good reassurance that I’m doing this right! I’m going to see what it’s going to take to get the rest of the “build pipeline” implemented. I’ll also see if Cruise is something that will work for us.

I already have so many books I’ve started reading and not finished, but Martin recommended another interesting one that’s still classified as a “Rough Cut”: Continuous Delivery by Dave Farley & Jez Humble.

II. Domain Specific Languages
I forgot my Hydrocodone in the car and my right-bottom part of my mouth was throbbing. The last time I took a pill was lunch and it’s been the longest stretch. I was a little distracted by that, so sorry for the significantly reduced notes.

Martin had an awesome explanation (in his book) about how to get from code configuration to XML configuration and then finally to a DSL configuration represented in Ruby. SO CLEAN! I really need to finish reading my books instead of starting new ones.

“XML is like violence. If it’s not working, you’re not using enough.”

Martin as also quite impressed about the possibilities of DSLs and the impact of Language Workbenches. He recommended us to watch this video from Intentional Software.

“If you try to solve a problem with regular expressions, you end up with two problems”

III. Controversial Topic: Diversity, Women & African American in Software Development
Although there were no slides, I didn’t really like this talk and I found it quite inappropriate. It is definitely a heated topic and should be discussed, but I don’t think this is the right forum. I’ll leave this topic alone.

We’re moving our hosting to a new hosting provider and just to make sure we don’t have any absolute URL paths, we want to blackhole ourselves from that domain.

With some instructions from Kevin, here’s what we did:Add one line:

Yeah, that’s it. Now my local machine goes to a blackhole when accessing the domains above. Awesome. Let the testing begin!

Pretty cool stuff. I just need to remember how to remove it after all this, that’s why I really posted this.

Something I was trying to do is update the version number in, for all simple purposes, a text file – something that’s not xmlpoke-able. So I have the property ready to go and the file I want to update!

My first thoughts were to use the loadfile to get the file into a property and replace it with the version.

Awesome, just like the sample and it echos out just fine…so now, how do I save my changes? After some digging around, I looked into the filterchain and read up on the copy task.

Seriously, copying a file now has the ability to modify the internals? Does not compute! Maybe copy, then modify. Anyway, its works now, so I can’t really complain anymore besides the hassle of finding the right task to do the job.

Now I know why James keeps telling me to get out of the XML HELL. Coding tasks in XML is just ass backwards.

• Source control – Subversion
  • TortoiseSVN
  • VisualSVN/AnkhSVN
• Continuous Integration – CCNet
  • Build automation
  • Test automation
  • Package automation
• Bug and Feature Tracker – Mantis
  • Notified using RSS in Outlook

You might be thinking, shouldn’t every successful software development team already have this in place to start with? Well, we didn’t and I made it a point to get it setup before I got too deep into code. Now, some of you might be wondering what we used before, but I’ll leave that to the previous development team to answer that. I joined the team on a green-field development project, most of which is the only C# we have. I was able to introduce new tools in order to help me track my progress and deliver products with confidence. Now, everyone on the development team is onboard with these tools.

Now, if you don’t know, I took a few courses from Venkat Subramanium, a pretty well known polyglot in the software development world, and I learned a lot about software development, best practices, and even picked up a few books just because of him. Who knew we have such a great asset at the University of Houston? GO COOGS! Anyway, I made it a point to use process, tools, and techniques I learned from his classes for the rest of my software development career.

Since then, and even more so while working at Secure Vantage, I’ve got pretty anal with software development. Especially about doing things the right way versus just getting things done, but it’s hard when we as a team have committed to a delivery date. I just follow that cost-quality-time triangle thing (what’s that called again?) and guess what always gets dropped first. I think I’ve been able to counteract that out with the Pareto Principle. On top of that, in the last few weeks I’ve been able to knock out a lot of those bugs put in the backburner to get where we’re at today. =)

So that’s cool, but what’s next for me? I definitely know I’m nowhere near complete. I’m going to have to start figuring out a way to manage the branching strategy, but I’m reading and hearing about so many different things it’s so overwhelming. For now, I’m just going to try my best and keep things as simple as possible. This is a new frontier for me, and I hope I’m ready for it. I need to get back to reading blogs, articles, and books again. I’ve fallen off that boat for far too long.

Oh, and today is my half-birthday!

My experience with this kind of event comes with much hesitance for me. I’m uncomfortable in an environment with a throng of people. Here’s a crazy fact about me: I learned the word “throng” from when I read Scarlet Letter. Many people in this case is about 2,500 people at booths and wandering around trying to sell stuff and ask for advice. It’s a sales thing, but the reason I’m going is for the sessions and to challenge my fears. I’m here to soak in all the information about new features as well as upcoming features for System Center Operations Manager (SCOM) and put myself in front of potential clients or just casual inquirers about our product line.

[Saturday]
I woke up in a mad dash to finish up washing clothes and packing. My flight was at 2:35 PM and I’m running around like crazy to get my things ready. After my last round of dried clothes are laid out on my bed, I make sure I have everything again and just in time to leave the house to head to the airport. I hate being a procrastinator.

Any way, I land, grab a little snack and met up with Kevin to wander around the strip. We picked up some drinks and checked out the Mirage’s new Volcano show. It’s freaking awesome. After little debating, we went to Wolfgang Puck. Everything was just freaking awesome.

[Sunday]

Work day. Enough said. The server room was in the bowels of the Venetian. After finding the command center, we went through a backdoor, downstairs to an elevator. After hopping off, we walked down through what looked like a service hallway. There was a door that required a key and that’s where we were, Floor .5. The Server room. Well after setting up our products to monitor the show’s network, I was eager to find a television to watch the Rockets play. We went to the AquaKnox and I sat myself directly in view of the game, awesome. it was the 4th quarter and all of the sudden everyone is standing up…NO!!! Well, good thing we just walked next door to some restaurant. We made a pitstop at the circle bar which is our typical meeting spot. Lavo was our last it stop for the night and for good reason. Waking up at 8:30 AM was not exciting. Thanks Coffee and Advil. Thanks a million.

[Monday]

I felt really queasy all day, but manageable. Before the Expo opened, we went to Grand Lux Cafe for small bite to eat. I had a small salad and maybe three spoonfuls of soup. Food wasn’t making me happy. The Expo was great, but like I said before this was something completely out of my comfort zone. Talking to wanderers who wanted to know general knowledge was nice, but the most fun was talking to the guys who wanted to know more about the product I actually develop. After the Expo closed, we went off to grab dinner at Pinot Brasserie. I was ready to pass out from hunger. By all means, I took care of the hunger.

[Tuesday]
The best session today was “Common Mistakes When Using Operations Manager and How To Avoid Them.” The speaker, Cameron Fuller from Catapult Systems, was very engaging: kudos to him. Tonight was a chill night with the Rockets. Too bad we lost, but its a home game coming up Thursday!

[Wednesday]
Sessions were good, but it seems like some speakers shouldn’t be speakers. I know I’d be horrible at it, so I know I’d never do it. Speakers need to learn to vocalize, hell it’s the most important thing to keep your audience awake. Good material can be presented in a monotone voice and makes it completely a bore. I also found it a little interesting that the speakers who loved to take in questions mid-sentence and interact with the audience to be the most effective. Other speakers who wanted to keep Q&A at the end seemed to be really focused, maybe a little too focused about what they were presenting rather than how the audience was taking it in. Any way, dinner with the company at David Burke was awesome. Thanks, Secure Vantage for taking care of us!

I finally hit the slots, up $30. Thanks to Wheel of Fortune and some random penny slots game I found interesting.

[Thursday]
NEVER have a cappuccino after dinner, EVER. I barely slept and was up at 4:00 AM for no reason. I tried going back to bed, but no success until around 6:00 AM. Today’s session was “Lousy Network Performance: Top 10 reasons the Network is Slow” by Laura Chappell. I’m definitely going to check out the tool she showed off, Wireshark. I’m also going to try it out on our network to see how we perform.

GO ROCKETS! Man, 12 years is a long time…

[Friday]

Last day and flight is at 6:25 PM. There are no shows during the day, so all we did was gamble and watch some sports. I was really glad to finally get out of there before I lost any more money.

]]> http://thomasnguyen.com/blog/2009/04/mms-2009-round-two/feed/ 0 http://thomasnguyen.com/blog/2008/11/first-year-on-the-job/ http://thomasnguyen.com/blog/2008/11/first-year-on-the-job/#comments Mon, 17 Nov 2008 15:51:00 +0000 thomasnguyencom http://thomasnguyen.com/blog/?p=236 First Week on the Job | First Month on the Job
(If this ever gets to “First Decade on the Job”, then WLOWL.)

Anyway, it’s been about a year now and things are awesome. I’ve completely changed both as a developer and an employee since I’ve started. I’m hoping for another great year with way more on plate. Consider this an “end of the year review” for myself.

Accomplishments both development (yay) and non-development related (sigh)

• Audit Collection Admin RC
• Audit Collection Data Miner Beta
• Audit Collection Syslog Gateway
• Subversion migration (with Mantis)
• Create MSI Installers (believe me, 32/64bit installers are beasts!)
• Email management, developer onboarding, document templating, manage third-party software repositories, website maintenance/updates.

Things I Have Learned

• System Center Operations Manager: what it is and how it is used
• Subversion: administration rather than just the TortoiseSVN part, still way more to learn on this
• Creating test users under the domain and using “runas” helps with testing
• 32-bit Vista will only recognize 3GB of RAM
• Windows Server 2008 Hyper-V is awesome!
• Having a laptop dock saves seconds of your life a day
• I don’t like Silverlight/WPF because of XAML. It’s ugly!
• NAnt is nice, but MSIs are what the customers want/need
• A downed Subversion Server on weekends makes for a really painful commit on Monday
• Outlook does not manage emails well nor make support migrating to new machine fun
• Sometimes working from home is way more productive
• Web and Win development has its own gotchas and fails
• Employers who trust trustworthy employees reap ginormous benefits (I think I’m pretty trustworthy)
• The grass is ALWAYS greener on the other side of the fence, but you might end up having to landscape it, weed it, edge it. In the end it will become what you make of it.

Things I Would Like (to Learn)

• Common Design Patterns
• Enterprise Architecture and Design
• One experienced C# developer (who enjoys the alt.net initiative) to brain storm and do code reviews.
• Someone creates MSI Installers for us (I hate them)
• Daily stand-up meetings with myself (yeah, I’m a lone developer)
• Subversion Administration (helpful hooks, scripts, and processes)
• Broadband wifi card (so I can work on the bus or just anywhere)
• I need formal, hands on agile training from JP, not just reading blogs
• Remove dependence on a cup of coffee a day

Areas of Improvement end of year reviews always come with this part

• Provide training for others on Subversion, Mantis, and knowledge sharing
• Ask for more feedback and detailed requirements
• Improve on product roadmap knowledge
• Understand more about customers’ needs and use of products
• Attend more User Group meetings to learn from others

Something I need to improve on is quality of life. This startup has a lot potential and a lot of things to do, but I need to find something to do outside of this. I have a huge passion for development, but I need to find something to do off the computer. I mean, even my side projects are web-related and I just recently got the Android SDK so I can start making stuff for my brother’s new G1. I’ll need to start jogging again to build up some stamina in preparation for our snowboarding trip in December. I CAN’T WAIT!!!

TOM ANGRY, can you guess why?