Vista disk space Just this morning I was in file explorer and I realized I only had 13.5GB of disk space available. Oops, not the way to start your day with a three month old laptop. A quick Google search pointed me to vssadmin. Then some general house cleaning including; clearing my event logs, temp files, etc and I freed up about 9 GB. Still not great but a heck of a lot better than before. Anybody else know of any Vista disk space hogs?
How To Reduce Disk Space Used By Windows Vista System Restore
Sat, 15 Sep 2007 80 Comments
Maintaining Development Momentum
New development is self fueling. Momentum is rarely a problem early off. The team is hungry to transform their ideas into code. Then as the refactoring and development proceeds design flaws begin to emerge and revisions being to happen. Depending on the severity of the problem it may be corrected in the current iteration or queued up for a future iteration. Working through these scenarios is what builds team cohesion. Overcoming design hurdles and major refactoring provides fulfillment and gratification for the team. The code base was solid before but now it is even better!
Iterations pass and depending on the size of the overall project the team may grow tired. During the early iterations when the energy levels are high you need to build up endurance and set the pace. I love to go full bore but that kind of pace cannot be sustained. This is why development teams needs to be thought of as a relay team running a relay race. Staggering iterations, or legs of a relay, among the team allows individuals "to pass the baton" and rotate off the critical path. This allows you to formulate strategies, based on your team’s strengths, for the upcoming iterations and keeping the team energized.
A few momentum killers
Disengaging the team or individual members for fire drill exercises are the single biggest momentum killer. Most iterations only last a couple of weeks. Management may try to pull people from an iteration to perform another task. From a managers viewpoint the individual completed their work for the iteration so pulling them to tend to another task makes sense. We all know this should not happen but it does and it will happen.
The nature of iterative development usually means subsequent iterations become more complicated and the pressure and stakes are higher. This occurs for an obvious reason: increased functionality of the code base. Do not allow yourself to under estimate iterations under pressure from above. This will happen and create additional stress for the team.
It's all about teamwork
Here are a few key guidelines I follow.
| • |
Have fun with your work. Smile and laughter keeps stress to a minimum and keeps you approachable to your team members. |
| • |
Lead by example. This kind of behavior is contagious. |
| • |
If you are a lead, stay involved as a code contributor. |
| • |
Make time for creativity. Don't schedule individuals with mundane tasks back-to-back. Their enthusiasm will begin to drop. Keep it mixed up. |
| • |
Make sure everyone has weekly goals/deliverables. Everyone should be working to contribute a piece of the puzzle on a weekly basis. |
| • |
Work as a team. Keep everyone engaged and involved in the decision making process. Collective code ownership. |
| • |
Pair program liberally. When working on complex algorithms or refactoring code work in pairs. The creativity can really flow. |
| • |
Police each other. Multiple people should have an understanding and contribute to functionality across the code base. Two or three minds work better than one. |
| • |
Track project metrics from the start. These metrics are vital to estimating future iterations. Use these metrics to back up your estimates and keep the team out of the pressure cooker. |
Fri, 10 Aug 2007 1 Comments
Pair Programming: my definition Without looking at how so many others have define pair programming. Here is my authoritative definition, "Combined mind power seated in front of a computer to solve a difficult problem that should not be solved by only one.
Well, I can't resist one reference Ron Jeffries. On the off chance this is the first time you have ever heard the term pair programming :-) 
Fri, 03 Aug 2007 0 Comments
Visual Studio 2008 Tips 
Wed, 01 Aug 2007 0 Comments
Career goals for the next 6 months It is interesting timing that Jason Haley tagged me about career goals. I just finished up a six month project that consumed all my time. The astute will notice my blog has been quite for a similar amount of time. Before I can define my future six month goals I need to digest what I learned/accomplished over the last six months:
| 1. |
| Worked with Commerce Server API. Specifically profile, catalog, and order management sub-systems. |
| 2. |
| Full-blown development on virtual machines using VMware. Started out with Virtual PC but switched to VMware and have not looked back. |
| 3. |
| Agile development. Coordinated parallel development streams. Introduced development team to unit testing and TDD. Pair programmed, learned when it is a value-add. (Also learned how sweet VMs and terminal services can make pair programming with laptops.) |
| 4. |
| Performed countless branching and merges. A result of parallel development. Perforce, is a wonderful SCM tool. |
| 5. |
| Service enabled Commerce Server API using WCF. That sentence does not do the effort justice. |
| 7. |
| Tested SO Commerce Server framework using VSTS in a testing lab. Learned how vital performance testing, in a lab environment, is to the development process. This is a must do if a development team wants to learn the behaviors of their software! There are many performance/load testing tools on the market but for a developer's usage I feel VSTS is superior. Its Visual Studio so the learning curve for a dev is relatively low. Not to mention load and web tests are pretty much built from unit tests. |
| 8. |
| Analyzed and documented performance testing results. Actually spent a few days reviewing 4+GB of test result data and logs. |
| 9. |
| Developed some WCF best-practices (project layouts, namespacing, versioning pactices, proxy generation scripts). |
| 10. |
| Worked with Vista. Famaliarized myself with Vista nuances. |
| 11. |
| Re-enforced major testing principal - the author of the code must write the unit tests! During the last project the idea was to have a couple new developers to the project write some unit tests for a sub-system, which had no coverage, as a way to learn the code base under development. Not a horrible concept but a very time consuming effort. At times it was confusing for the devs trying to understand the behavior of code they are writing the tests for. That hints at another problem which could have been taken care of should the author of the code practiced TDD. |
| 12. |
| Learned how difficult it is to develop a framework... |
| Goals |
|---|
| 1. | Continue my quest for efficiency by practicing the Pareto Principal (80/20 principal). 80% of the outputs result from 20% of the inputs. Focus my efforts on the 20% and eliminate the rest. Also, read Getting Things Done. |
| 2. | Define and hone my current skillset. My current interests and focus are WCF, developing frameworks, TDD, and agile development. Over the next six months I will focus on these areas. Specifically I hope to capture and build upon the agile development principles that have worked for me. WCF related I want to dig into the internals. For many years I have tried to consume all the latest information only to do little with it. The shotgun appoarch to staying up on technology just isn't fun anymore. |
| 3. | Write blog entries. At a bare minimum one entry per month. Wow, what high expectations! Writing blog entries has been hard for me in the past as I feel I have to be a SME (subject matter expert) to be worthy of discussing a topic. As many bloggers can attest this not the case. Stay tuned for more. There is lots floating around in my head and its time to get them out in words. |
| 4. | Look into developing a product. Over the next six months I would like to create a few POCs to prove out some ideas. If they pan out maybe I will take the next steps. |
| 5. | Do a presentation for a user group or Code Camp. I am long overdue to take the plunge into these waters. Enough said, action required. |
| 6. | Catch up with individuals within my network. Find out what people are currently working on and their future plans. I have not taken the time to do this in a while. |
| 7. | Learn more functionality provided by CodeRush and Refactor! Pro. These tools are key productivity enhancers. RefactorPro will be of special interest as I am currently only using a fraction of the refactorings available. |
I just noticed that the above goals are all just detailed versions of my anual goals. I did not even try to do that. Guess that is proof that writing down your anual goals does commit them to your subconscious. 
Wed, 01 Aug 2007 8 Comments
WCF Bloggers and Forums Lately I have been spending my spare time working with WCF. There are still only pockets of knowledge about WCF (although it is growing every day). Here are the blogs I look to for info. Let me know if you know of a WCF blog I should check out.
Also, here are the two WCF forums I use.
Sat, 03 Feb 2007 0 Comments
|