-
-
Our very own Bryant Smith has revamped his conversion of Martin Fowler's refactoring example (originally in Java) to now cover both C# and VB.NET.
You can find the article here with the relevant downloads and walkthrough.
Martin Fowler's example works nicely because it is a simple class structure that is easy to understand. It also has enough complexity to allow refactorings like MoveMethod to show how data and operations should be related. I also like Bob Martin's refactoring example on generating primes but it doesn't have much of the OO feel since the whole thing is really just one method being broken out with little instance data. Both examples are great for debating techniques and trying out new ideas. A book filled with refactoring puzzles would be a great resource ... anyone?
Our team has a weekly Friday morning meeting where we experiment with new techniques and ideas - we have done both of the mentioned refactoring examples by breaking our team into programming pairs and then comparing their solutions at the end. This is a lot of fun and allows the team to experiment with refactoring ideas outside of the deadline crunch. Both examples have worked well in this environment and have helped to spread adoption and familiarity of refactoring techniques across the group. Of course, everyday pairing also helps but sometimes it is nice to refactor it several different ways and then compare approaches (something a client might not be too excited about! :)) - although the learning experience is fantastic.
If you are interested in joining our team where we practice Test Driven Development, Pair Programming and Refactoring daily - we are hiring.
Jonathan Cogley is the CEO and founder of Thycotic Software, a .NET consulting company and ISV in Washington DC. Our product, Secret Server is an enterprise password management system for teams to secure their passwords. Where do you keep your passwords or do you use the same password everywhere?
-
-
Do you space out your code so there are line breaks between the pieces of logic? Why do you think this is necessary? Typically this is done to separate chunks of logic so that they can be easily distinguished. If it is a complicated enough chunk, then it may even make sense to put a comment at the top of the chunk. At this point, the Agile police will jump on you and tell you to turn your comment into a method name and perform an Extract Method refactoring. This is great practice (fellow Agile police member here!) and it makes a lot of sense since it abstracts the concept and makes the code more self describing.
But let's think back to those line breaks again ... if it needed the line breaks, then there is code smell. If your code needs whitespace in the method to make it cleaner to read then it is probably doing too much. Of course, this is very subjective and easy to argue (heck - our team can't fully agree on this either!) but think carefully the next time you find yourself adding extra whitespace to your code and think:
- Is this code as simple as it should be?
- Does this logic all belong here or could it be broken out into other methods/classes?
Jonathan Cogley is the CEO and founder of Thycotic Software, a .NET consulting company and ISV in Washington DC. Our product, Secret Server is an enterprise password management system for teams to secure their passwords. Where do you keep your passwords or do you use the same password everywhere?
-
-
Many developers in our industry prefer a dark corner to the presentation podium. This is often explained away with references to introverted personalities and geekish tendencies. While this may be true for certain individuals, there are definitely many benefits to breaking away from this stereotype. One of the best ways to progress in the business world is to develop strong communication skills - customers want to be understood and the combination with technical ability provides a powerful skillset when understanding problems and providing solutions. As with so many things in life, excellence in communication can be achieved through lots of practice.
Pair Programming is the process where two developers work together on the same code with one person typing and both constantly discussing the requirements, design and code. Pair Programming also provides an excellent opportunity to hone your communication skills. To be "in the zone" when pair programming requires that you continually verbalize your ideas in a way that your pair partner can follow your thinking and stay engaged.
This sounds easy, but to do it effectively requires:
- Verbalizing raw ideas as they come into your head in a way that your pair can follow
- Asking questions when you don't understand
- Focusing on someone elses way of thinking to stay engaged in their thought process
- Moving in a methodical way so that your pair can keep up
- Compromising on an approach to a solution and agreeing together on the next steps to take
Any periods of silence when pairing can often indicate a problem:
- The pair is stuck and doesn't know how to proceed
- One or both members of the pair are distracted and are no longer engaged
- One member of the pair is driving while the other has lost interest
- One member of the pair is proceeding without explaining their actions to their partner (and that partner has given up asking questions)
As you can see it requires a lot of effort and mostly soft skills to bring out the best in your own technical thinking and that of your pair partner.
We value communication so highly that we practice Pair Programming wherever possible on our development team. We also encourage our team members to present at development team meetings, user groups and code camps to further improve their communication skills. This is good for our team in that our productivity is enhanced through all the apprenticeship/cross-training and our verbal/soft-skills are enhanced daily through all the practice.
Come along to the upcoming Code Camps in the Mid-Atlantic area to see several of the Thycotic team members present and many other great speakers too.
Jonathan Cogley is the CEO and founder of Thycotic Software, a .NET consulting company and ISV in Washington DC. Our product, Secret Server, is a secure web-based solution for teams to secure their passwords. Where do you keep your passwords or do you use the same password everywhere?
-
-
John Morales has a great post on understanding complexity and how to think about difficult concepts.
I think John hits on a key concept in the idea of "good code" while I realize it wasn't the main focus of his post: good code is simple for everyone (the team in question) to understand. I think this falls in nicely with our typical #1 goal on projects - writing maintainable code.
I always smile when I hear the saying "if it is was hard to write, it should be hard to read" and nothing could be further from the truth.
Remember the three purposes of code according to Bob Martin:
- Perform the job (in other words, actually work)
- Be maintainable
- Clearly communicate its intent
Communicating clearly typically means simplicity for the intended audience.
In many ways, writing good code is like teaching. A good teacher will keep the message clear and simple and appropriate for their audience. In tackling a difficult programming task - our job is to bring the right metaphors for the system and team, then present it in a clear manner that we will easily understand in 6 months and the most junior person on the team could maintain (sometimes a tall order but who said things were easy) and therein lies OUR challenge.
Nice post John! :)
Jonathan Cogley is the CEO and founder of Thycotic Software, a .NET consulting company and ISV in Washington DC. Our product, Secret Server, is a secure web-based solution for teams to secure their passwords. Where do you keep your passwords or do you use the same one everywhere (snicker)?
-
-
A very intelligent person once said:
"If I have seen further it is by standing on the shoulders of Giants."
The person in question, is of course none other than Sir Isaac Newton. He was able to go further with his discoveries because others had solved some of the details already and provided a layer of abstraction for him to improve upon.
When doing a code review, I often encounter a little defensiveness. Since we practice pair programming almost exclusively, this code review usually happens when reviewing code (as a pair) to make a change for a new feature or bug fix. Often the code was not written by the pair reviewing it so it becomes easy to get offensive instead of defensive. Either way, this works against the purpose of the code review and can be solved by thinking about the code review in a different way...
The pair (or person) who wrote the original code was dealing with different complexities and challenges - they solved these problems with the code in question. Our job when reviewing is not to solve these same challenges but rather to look at *their solution* and decide how it could be improved. In this light, it is very unfair to compare our improved solution with theirs since we had a very different task. This is a subtle but very important distinction. Remember this when doing code reviews and it should help you to move beyond the personalities and egos involved (well, maybe :)).
How do *you* solve the human challenges of a code review?
Jonathan Cogley is the CEO and founder of Thycotic Software, a .NET consulting company and ISV in Washington DC. Our product, Secret Server, is a secure web-based solution for teams to secure their passwords. Where do you keep your passwords or do you use the same one everywhere (snicker)?
-
-
This is my second post with Live Writer and so far it seems pretty good. We have been using BlogJet for a while and really like the intuitive interface although it seems like Live Writer has most of the same features. Being able to easily pull up an earlier blog post to make a correction is such a great feature for me since I always spot typos or missing links after the post goes out. I was also very impressed with the easy configuration of Live Writer - I simply pointed it to my blog url, gave my username/password, it prompted me for a blog engine type and then suggested a post URL and it all just worked!
I have not yet tried any of the file attachment features or the integration with maps (not sure about the need for that one!). So here goes an image:
and it just works ... no FTP configuration, nada. Wow! That is awesome.
I am running Live Writer on Vista Enterprise after making the switch to Vista about a month back. I still don't have a development environment on Vista but I have tried our team's VMWare development instance of XP with some mixed results - VMWare seems to work on Vista but just hangs for a while every now and then.
Jonathan Cogley is the CEO and founder of Thycotic Software, a .NET consulting company and ISV in Washington DC. Our product, Secret Server, is a secure web-based solution for teams to secure their passwords. Where do you keep your passwords or do you use the same one everywhere (snicker)?
-
-
I presented on Pair Programming at the Maryland ColdFusion User's Group on Tuesday and was very pleased to tell everyone about all the upcoming Code Camps in our area. I also promised to post the links to the group, so here they are:
Thycotic is buzzing with Code Camp excitement and everyone has been submitting session proposals and coordinating topics. We should have a good showing from our team at the Code Camps with presentation topics ranging from Cryptography, Secure .NET Programming, NHibernate, DotLucene to RhinoMocks and Agile .NET.
Code Camps are a great way to learn about new technology and connect with your local developer community.
(If you are looking to join a developer team that encourages learning on a daily basis, pair programming and test driven development ... we are hiring.)
Jonathan Cogley is the CEO and founder of Thycotic Software, a .NET consulting company and ISV in Washington DC. Our product, Secret Server, is a secure web-based solution for teams to secure their passwords. Where do you keep your passwords or do you use the same one everywhere (snicker)?