1. 12 Steps to Better Code

    Just came over the amazing article The Joel Test: 12 Steps to Better Code written way back in 2000, but it's still 100% true! Actually IMHO we could improve the article slightly (today after more than 10 years since original article was published)

    • It’s worth to add there something like – “Do you use any Test First Development technique?
    • Also “Do you have a spec?” could become something like “Do you use Acceptance Test Driven Development (ATDD)?”
    Interesting thing is that I read that article several years ago and it was very fun to read it now to compare my perception. …


  2. Acceptance Test Driven Development (ATDD) principles

    Acceptance Tests are very similar to the Functional Tests. And they actually are the Integration Tests. The main idea of the Acceptance Tests is to create Executable Specification (Spec) for the project. And that Spec will be readable by humans and machines. So ideally it could stand in place of requirement documents. To generate document all we need is just run Acceptance Tests with an parameter. Such reports could be send to the customer on the end of each iteration and could be available all the time on the CI server. It's the main advantage of the Acceptance Tests as for me. …


  3. Offshore development… and software defects

    Just read interesting overview of the Offshore development related issues. The main point is that NON Co located projects will have approximately 2.8 times as many software defects as Co located projects! Amazing thing is that Agile could fix one of the Offshoring issues (Many Defects), by cleaning up defects as earlier as possible. Since we deliver smaller releases we are able to make carefull testing of all features. So defects will be fixed earlier with a less price.


  4. CoffeeScript, Sass and Less (support for Visual Studio)

    There are new amazing stuff an Scott Hanselman’s blog (as usual Smile)! He wrote about Mindscape Web Workbench extension for the Visual Studio, which adds CoffeeScript, Sass and Less support into it. As for me I really liked CoffeeScript & Sass. Below are some quotations and screenshots from the original article. …


  5. Agile Development Management Tools

    Just read interesting research The Forrester Wave™: Agile Development Management Tools, Q2 2010 I was a little surprised that TDD, BDD, FDD are the separate Agile methodologies. Previously I was totally sure that things such as TDD & BDD are just a way to Improve an (any?) methodology! …


  6. ASP.NET MVC 4 Roadmap

    ASP.NET MVC 4 Roadmap is out there! There are so exciting themes such as simplify development process for the tablet and mobile devices (HTML5), make it easier to deploy and hosting MVC application in the cloud (such as on Windows Azure) etc. …


  7. Stateless. A C# Hierarchical State Machine.

    Today I finally got some time to research Stateless And you know, it’s awesome! Key features:

    • Generic support for states and triggers of any .NET type (numbers, strings, enums, etc.)
    • Hierarchical states
    • Entry/exit events for states
    • Guard clauses to support conditional transitions
    • Introspection
    • Ability to store state externally (for example, in a property tracked by Linq to SQL)
    • Parameterised triggers
    • Reentrant states
    Let's consider the following example (it's available in the Stateless source code). …


  8. ASP.NET MVC Profiler

    Just reviewed simple but effective mini-profiler for ASP.NET MVC 3. As for me it’s most useful feature is Database profiling. It’s supports Entity Framework and Linq-2-SQL out of the box. So please don’t hesitate and give it a look Подмигивающая рожица


  9. Why Software Fails

    Just read very interesting article about why software fails written back in 2005. If you are working on IT projects I’m totally sure you’ll find it worth to checkout. …


  10. People and Methodologies in Software Development

    Just read People and Methodologies in Software Development by Alistair Cockburn. Key conclusions:

    1.  The members establish conventions for their interactions — a base methodology — at the start of the project. This can be likened to them "programming" themselves. 2.  They then perform their jobs in the normal scurry of project life, often getting too caught up to reflect on how they are doing. 3.  They schedule regular periods of reflection in which they reconsider and adjust their working conventions. These results have been used successfully on several industrial projects having the usual time and cost pressures on the staff.
    There are interesting descriptions of the word methodology:
    It is the roles, teams, skills, processes, techniques, tools, and standards used by the project team
    If it is what one or two people do while working on a task, it is technique. If it is what the team uses to coordinate their work, then it's methodology.
    Any conventions and policies the team relies on to successfully deliver systems