We are optimistic by nature, but sometimes we should just be professional.

 

Here is one situation I see repeating from time to time (to me, or my fellow developers). I have a coding task (small development, small bug, doesn't matter), and I know exactly what needs to be done in order to solve it. I know that functionality very well, I am familiar with that code, the confidence is high. I could make the change with my eyes closed, and it would solve the problem for sure.

I make the change, and for some reason I decide that nothing can go wrong and I don't need to test it. For me, some of these reasons are:

• I have to get to something else quickly
• I don't have enough patience to test it right now
• the client needs this change right now

I quickly commit the change on SVN, move on and forget about it.

 

The result, a few hours or days later?

I can't believe it! I didn't realize that [something bad related to the change].

If I'm lucky, the person who observes the problem is someone from our testing team. Unfortunately, if I install the change directly on the production environment (due to client pressure) I can't be lucky.

But... if I'm lucky, the change does not break anything new. It just doesn't work, because it needs an additional change in order to work. Again, sometimes I am not lucky.

 

Here is why this happens: we are not computers, and we can't calculate all the implications in a situation unless it is very simple and without implications. Also, we sometimes forget things.

In software, actions generate effects. If you rely on your mind to control these effects, you will run into problems. In order to be efficient, you need to test the result in an objective way: the simplest (and usually slowest) method is to run the application and see what happened after the change, the sophisticated (and correct) method is to have automated tests.

So, unless you are changing the text in a label, resist the pressure / temptation and test the change before doing the commit.

One thing which can present a challenge for a team is sharing knowledge between team members in a systematic and continuous way (especially over long periods of time), without decreasing the efficiency of each member through interruptions from his work, meetings or presentations.

I am not saying that meetings and presentations are not good, but they are too organized in nature and they don't fit this challenge very well for various reasons. What I am looking for is a solution which can stand the test of time and is very easy to apply while being flexible enough to let anyone use it when and how he wants to.

 

Here is a very simple development example: let's say I am working on a functionality and I decide I need an extension method for the List class. I create the extension, use it happily and move on with my task. Of course, any time I will have a similar need I will reuse the extension because I know about it.

There is only one thing missing here: no one else in the team knows about it, even if it might be useful to them.

This pattern can apply to all sorts of things that happen in a team: tools, concepts, ideas, processes, etc.

 

How do we solve this problem?

For now, I will try to use email as the communication mechanism and see how it goes. Keeping in mind the previous example, one approach could be this: before moving on with my task, I will send an email to the the development team and let them know about the new tool (the extension method).

Another approach (which I like better) is making a quick note about it and move on with my task immediately. I am using SlickJot for this. From time to time, I review the list of things to announce and take some time to prepare an email with all of them.

I write the email when I have the time, and the other team members read it when they have the time. No restrictions, no pressure.

 

This mechanism might solve another tricky problem: introducing a new team member in a team / project. I intend to store all these emails in one place for each project, and send the archive to the new project member. This should quickly get him up to speed with many things.

 

It also introduces an interesting idea: in a team (especially a software development team), the value of a team member is given not only by how good he is but also by how much he shares (in an efficient way) with others. This is like internal team blogging (but simpler and faster), and the best bloggers bring the most value to the entire team.

With a good communication process in place, everyone will have many benefits from something like this.

 

I can't believe how much ReSharper is helping me. I am getting used to working for 4-5 hours without doing a single build, and have a successful build (or one with very few errors) when I finally do it.

It seems to be able to show me during development almost anything that could go wrong, which saves me a lot of time.

Not to mention the application-wide refactorings about which I couldn't even dream without a tool like this.

 

Before using a Web Application Project, I was used to:

• making changes in any website file and hitting CTRL-F5 to get the changes built on the fly
• making changes in any project from the solution, building only that project, and hitting CTRL-F5 to automatically get the new dll version in the website's /bin directory

With the Web Application Project these tricks don't work anymore, and it made me ask the classical developer question 'Why doesn't this work (I did everything that was needed)?' a few times already.

The thing that fortunately still works is making changes in the UI(.aspx, .ascx, .css or .js files), and hitting CTRL-F5 to get the changes updated in the browser.

 

I am slowly getting used to building the website more frequently, but the real solution will be a more efficient build mechanism (probably with nant).

 

UPDATE 09.29.2008: Today I got back at the office and I checked if the file has really been deleted from the desktop computer where I modified it on Friday. It was not deleted, it was just excluded from the list of SVN maintained files. This explains why it did not go to the repository on commit, and why it did not arrive on my laptop when I did the update.

The conclusion is that SVN is really smart (and I am not): because the local version was different than the one which was deleted from the repository, it simply excluded it from his list instead of deleting it. This is probably the best solution, because it does not create problems in the repository and it also gives me a chance to recover my code. If only I would pay attention to the messages.

I did the test below with a local file that was similar with the one in the repository, and this is seemed to work (it was deleted at the update). Which is also a correct move from SVN.

 

 

Yesterday I was working on the same class with a fellow developer, and at the end of the day he told me that he split it in 2 separate classes. I was focused on my work and did not think about the implications immediately... but I really should have.

As usual, before leaving the office I did a full commit... after a full update, because SVN told me I have to do an update before committing. I did not pay much attention to what happened with the files during the process... and again, I really should have.

One day later I am looking at the code, and I realize that he also renamed the class. And the next thing I do... I am searching for the class where I did my changes, and it is no more!

 

Here is the explanation: when updating, SVN observed that the file I have been working on had been deleted. So it simply and silently removed it from my local directory. This kind of cool update goes something like this:

(and ends with the ironic TortoiseSVN Finished!)

 

Because I did the update before committing, this means I also lost my version of the file. The good part is that the file had only a few changes made by myself, so this time it's not a disaster.

 

But it's a good lesson to remember when two developers work simultaneously on the same file.

 

You can read about the purpose of this list and how to use it here.
Also, the list of resources is here.

 

1. general implementation
2. concepts
   1. harvested framework
      watch out so you don't fall into the trap of building frameworks up front. It's generally better to let them show themselves in your code and then you go from there.
   2. YAGNI
      So it's important to be careful and not think "You Aren't Going to Need It" (YAGNI) too often when it comes to operational mechanisms. Using YAGNI often will cost too much when it comes to adding the mechanism if (or rather when) you will need it. Remember, the idea with YAGNI is that the cost of adding something is pretty much the same now and later, in which case you can always wait until you really need it. When the cost is low now and high later, and there's a good chance you will need it, you should make a different decision.
      going for a Query Object, especially a domain-specific one, or the Specification pattern is to start by going too far, too quickly, don't you think? Let's go for the simplest possible and only consider two of all possible criteria for now
      The third solution could be to create an interface called ICustomer (or something similar, or let Customer be an interface) and then create a stub implementation of the interface. Again, that feels like overkill right now, and what would the purpose be when moving forward? To be able to swap ICustomer implementations? Is that really something I expect? No, I don't, so until proven wrong, I decide that this isn't the solution I am going to start with.
      Well, what value does the factory really add? Not anything yet. It just adds a bit of complexity. I really should have at least started without the factory, because it shouldn't be around if it doesn't add value. It feels strange to refactor away from a factory. But it's just a sign that I got carried away and started out with a too detailed design from the beginning.
      B4
   3. whiteboard or sketchpad for software design meetings
      Diagrams are a means of communication and explanation, and they facilitate brainstorming. They serve these ends best if they are minimal.
      resources
      B1
   4. Strategic Design Decision Making
      Strategic design requires minimalism and humility
      resources
      B1
   5. source control
      1. SVN
   6. Software Factories
      The idea of Software Factories is to have two lines in the software company. One line creates architectures, frameworks, and such to be used for families of applications. The other line creates the applications by using what the first line has produced, and thereby amortizing the cost of the frameworks on several projects
      A problem is that it's troublesome to just invent a framework. It's probably a better idea to harvest instead. Another thing that is somewhat problematic with Software Factories, though, is that they probably require pretty large organizations before being efficient to use
      At the heart of Software Factories is that of Domain Specific Languages
      resources
      B4
   7. risk management
      except when the team has proven skills and the domain is very familiar, the first-cut system should be based on some part of the CORE DOMAIN, however simple.
      the CORE DOMAIN is high risk because it is often unexpectedly difficult and because without it, the project cannot succeed.
      resources
      B1
   8. project documentation
      Documents Should Complement Code and Speech
      resources
      B1
   9. continuous integration
      The key to significantly reducing integration problems is to generate your builds automatically and to use an incremental integration strategy where all the code is rebuilt and tested at least daily, if not continuously. The idea is that if your recently added code breaks a build, you either fix it immediately or roll back the changes to restore the system to the last known good state.
      resources
      B4
   10. bug fixing
       It's a good idea to use TDD and refactoring for bugfixing also. First expose the bug with a red test, then solve the bug so you get green, and then refactor.
       resources
       B4
   11. Big Design Up-Front (BDUF)
       I think it's pretty well known that a Big Design Up-Front (BDUF) has some big problems. At the same time, most often we know some things from day one. It's a matter of balance.
       resources
       B4
   12. automated build & deploy
       code & implementation
       E2

 

You can find the entire list of techniques in progress in the Development base concepts category. Please feel free to leave any comments or suggestions which could make these lists more useful for everyone.

Also, if you are interested in learning these skills you can try the Developer training modules.

 

Our team has started a new internal training project for our developers, and I will post here the modules as we prepare them. We already tried variations of this a couple of times in the past and it went well, but this time we are using a simpler concept which I am sure will bring excellent results. Here are the basic ideas:

• the material will be organized in modules, and we will probably create a dependency map

For example
- you need to go through Layering before you do Domain Driven Design
- you need to go through Domain Driven Design before you do Design Patterns or TDD
- you need to go through C# 3.5 before you do Linq
etc.
This map will serve as a guide, but the developer will be able to approach the techniques and technologies in a different order if that will be more efficient.

• anyone can start where is best for him and follow the path that is most appropriate and natural
• anyone can start any module at any time, and the period will be defined in each particular case
• modules can be added at any time
• each module consists of learning + evaluation
  

The evaluation step should motivate the developer and help him find out if he needs to insist more on the subject or any particular areas of it

• the direction of each module will be given through keywords and key concepts that need to be known and understood, not through a strict set of learning material

The developer can search and read other material if that will serve the defined purpose.

• the material will be text, audio, video, etc., to help each type of learner
• the resources will be of any kind (books, blog posts, podcasts, webcasts, articles, open source code, etc.)

 

You can find the entire list of training modules in the Developer training modules category. Please feel free to leave any comments or suggestions which could make these modules more useful for everyone.

Also, you can find more information about the techniques involved in the Development base concepts section.

What a great lesson I received today! It is the second time when this happens to me, and I feel a bit stupid because I forgot it... but they say it's never too late, and I hope next time I will remember.

Here is the pattern:

• the client asks something which translates into a big set of repetitive tasks

or

• something happens in the application, and to solve the problem you need to do something which translates into a big set of repetitive tasks

This time it was the second case, but it did not look that bad. It seemed that with 3-4 hours of work a developer could solve the problem, so we tried. This was yesterday.

Today the developer finished the work (it took more than expected), just so we can receive word from the client that a lot more of this repetitive work was needed. We jumped into calculating how much time it will take, and our morale went down for the next few minutes.

We would have probably started the work anyway, unless another colleague who was listening to our discussion wouldn't have interrupt us: but what if you trick the application into doing what it did not do the first time, instead of doing the work manually? After discussing for 5 minutes we realized how easy it was, and after 1 hour the developer finished the work. This was great, and it saved us a lot of time.

Conclusion:

When a repetitive task can last more than 2-3 hours (and especially if it might come back with other occasions) don't jump into solving it by hand. Have courage and automate it!