Articles, Continuous delivery

Dev-team Awesomeness Quiz. List of development practices.

Hero-Envy-SupermanThis quiz is to let you evaluate your team/project in terms of good practices. Below you will find a list of different development practices/techniques. Mark the practices you use in your project and sum the points assigned to each technique. Then you can place yourself on the right place on the awesomeness scale. Be frank with yourself – don’t mark “UI testing” if you have one UI test that produces unknown result or “Friday (20% of time)” if you once stayed longer at work to do some refactoring.


Description Points
Source Code Versioning Using SVN, Git, etc. (instead of shared disk space) 2
Using build server Separated machine compiling the solution, running tests and publishing the results 2
Automatic versioning Assigning application version by buildserver 1
Clean build No warnings while building the solution 1
Code quality rules Having and following a list of code quality rules checked by buildserver. Build fails if not passed 1
Code quality metrics Measuring “code coverage”, number of lines of code, number of unit tests, cyclomatic complexity 1
Separated tester role Having a tester whose only responsibility is testing the quality, doing regression tests etc 1
“One click” deployment Using WebDeploy or any other script that lets to deploy the software in less than few clicks 1
Continuous delivery Continuous integration + automated testing + continuous deployment 2
Database upgrade script Database migration is done automatically as part of deployment 1
Database refactoring Database is refactored, there is no left stored procedure/table, no “obsolete” fields 1
Pair programming Two developers + one computer 1
Code review Each commit/functionality is reviewed by another developer 2
External code audits Code review done by developers from the outside of the team 1
Friday (20% of time) Every month/week/”on Friday” stop doing productive staff and hold on to refactor something 1
Maintain central documentation, wiki Describe important information/workflows in one place and keep updating 1
Work agile Contact with client, work in iterations (not only Scrum) 1
Unit testing Non-production code testing small parts of production code 2
TDD Test-driven development: write test, write code, refactor 1
ATDD Specify requirements as automated tests 1
BDD Test whole behaviour not just parts of code 1
Discuss BDD scenarios with customer Customer utilise BDD scenarios, they can be written with specific language (i.e. Gherkin) 1
Non-back-end unit testing Unit testing of other parts of source code, for example JavaScript 1
Automated UI testing Automated tests of scenarios using user interface, using tools like Selenium, WatiN/WatiR 1
Performance testing Load tests, stress tests, analysing reports 1
Integration tests Automated testing of integration with other systems (i.e. exposed service endpoints) 1


1. [0 – 5 points] Ok, this is probably one-man academic project or a simple website. But at least you have found this list of ideas. Each month peek one and try to experiment. The benefits are invaluable! The great pleasure of seeing the build server full of green signs of passed tests… Can you imagine the feeling of safety when refactoring your code or UI? The instant feedback from users and the awesome feeling that you and your project are awesome and can be mentioned as an example to follow. This all is a bread and butter for mature teams.

2. [6 – 11 points] Is it that you are willing, but you don’t have time? No one does. Is your project too small? Notepad.exe has more that 200 UI tests. Think, that the next person that will take over your project in the next 6 months is a serial killer that knows your address.

3. [12 – 18 points] This is great that you came to this point. You passed the test. But be aware of the fact how many things you can improve. Remember that there are better projects, easier to maintain and refactor.

4. [19 – 25 points] Excellent work. This level is sometimes the maximum for some projects. Your team/project rules. People can actually mimic your way of working, I’m not telling that you must go now ask for a rise, but of course you can try :]

5. [25 – 31 points] You are simply awesome. You’ve reached the top. You are like Chuck Norris in development Texas and you turned “GodMode” in your project. Keep it up. PS: Do you still remember about earning money?

Final note

This was just my proposal of practices used by developers. It’d be fabulous if you add your ideas in the comment. I promise to add best ideas to the list!

You can also share your score if you want.

Programming (back-end)

Handling DialogBox with WPF (MVVM)

imageHandling dialog windows in WPF using MVVM pattern is not such obvious thing as people may suspect. There are many discussions about it, and people come out with some solutions, that are more or less difficult, but still not perfect. I don’t like any and it made me describe my own.




Common solutions

As I have found, there is a couple of solutions for the problem. The most common ones are:

  • DialogService – creating a service used to handle all dialogs/windows in the application. Such a service can be used by any ViewModel. This way the view model knows that some other part of application must be shown/hidden as a dialog window. It’s somehow a design smell (link1, link2, etc.)
  • Dialog content injection – declare a markup of the dialog in XAML. Such a markup is then used to generate the new dialog window. Its visibility is controlled by a binding between ViewModel’s “Showing” property and the View. I thinks it’s better than the first one, but there’s too much logic behind the scene (link)
    Simplest approach

I think both solutions don’t answer my real need. I had a chat with an architect about this and we came to some simple conclusions:

  • MVVM is to create a good separation of presentation layer and the rest of the application, mainly by using bindings
  • Showing some UI parts as a dialog window or a panel, tab, accordion etc. is a presentation detail. It should be responsibility of the to control such a behaviour.
  • View doesn’t need to be stupid. WPF+MVVM developers got used to moving all the view code to bindings, but let’s not overuse it. If something is simpler to be done in code-behind, let it stay there.

In the end, I decided to invoke the famous “ShowDialog” method in the code-behind and pass the context (view model) to the newly created window. In the simplest case the view should not process the DialogResult, because this is the view model’s role. In my case the communication between the view model of the “Main window” and view model of the “dialog window” is based on events. Such a “Save” event exposed by the dialog’s view model can be used by “Main window” view model to add some item to a collection/repository but in the same time it can be used by the view of “dialog window” to close it.



The most beautiful words will never reflect the beauty of a sample, so here it is: Link