I’ve recently been reading a few articles about the future of application development and IT infrastructure management. I believe that one of the main issues that face most IT pros is that we get caught up in the buzz word factory. Today’s latest: Cloud computing, Web 3.0, etc. What we fail to realize when we speak about the future of our architecture is the changing dynamic of our end users.

Most roles within scrum are clearly defined: product owners, developers and even testers etc..., but what about the role of scrum master? Without a dedicated project manager stepping into the realm (especially in small teams), this appears to a bit part role that is passed around like 'pass the parcel' hoping to find the most suitable team member fit for the job.

I implemented a small part of SQL to see how close I could match it within Scala.

As a developer I have made an habit of using the keyboard for the majority of tasks. Vim for example is my favorite text editor, which does not require point-and-click. This is a productivity requirement: the less my fingers move between the keyboard and the mouse, the faster I am in consulting documentation and other developers' blogs; vim even goes further and lets you scan a document without leaving the home row.

Test-Driven Development, or TDD, is often quoted as an essential Agile best practice, and so it is. It works wonders on green-fields projects and new code bases where you can start afresh and ensure that all your code is both easily testable and well tested. But what about legacy code? (By legacy code, I mean any code that does not have a comprehensive set of automated tests, so you might be writing legacy code as we speak).

Alan Baljeu was trying to use TDD with his large, legacy C++ code base. He found that the principle of the simplest thing that could possibly work was causing him trouble with the amount of rework.

Every OOP fan is almost by definition a fan of polymorphism. Lots of otherwise good books (e.g. Fowler's Refactoring) go so far as to say if you use runtime type checks, e.g. Java's "instanceof" operator, then you're probably an evil person who threatens little children with switch statements.

Featured this week: Blame and Guilt - Agile Antipatterns; Too Much Meeting and Discussion, Not Enough Coding; The Trainer/Consultants dilemma, ....

In C++ Programming Language, increasing a value by 1 is called incrementing and decreasing value by 1 is called decrementing. As 1 is the most common value used to add, subtract and to reassign into variable.The increment operator(++) increases the variable's value by 1 and the decrement operator(--) decreases the value by 1.

Some reasons why you should include third party libraries in your repository

Here is an interesting problem that I am facing. I have a pretty good working knowledge of computing, and while I can usually manage to get the gist of a new technology in a short amount of time, that is only useful for talking about it, not actually applying that. I am currently trying to figure out the parts where I am missing, and plug the holes. And I am running into a bit of a problem here.

This post is a summary of my lessons learned from leading distributed teams. I've managed distributed project teams since 2001, spanning the UK, Argentina, India, and other parts of the world. While I preferred having everybody together on site around a whiteboard to simplify and improves communication, flexibility with distributed teams gave me access to the right talent, wherever it may be.

Recently I wanted to add a very simple sanity check to our sites’ build. Typically the Integration/Selenium RC tests would handle this sort of thing, but I wanted something light enough to go in continuous integration build so we would be protected from simple dll version mishaps, configuration errors, container issues, whatever. There’s probably plenty of ways to do this, and if any of you know of a better way, please let me know.

Paul asked me to review this, his first book, and my comment to him was that he had a pretty high bar to match; being of the same "series" as Release It!, Mike Nygard's take on building software ready for production (and, in my repeatedly stated opinion, the most important-to-read book of the decade), Debug It! had some pretty impressive shoes to fill. Paul's comment was pretty predictable: "Thanks for keeping the pressure to a minimum."

A recent polls shows that people are not using more tools for software configuration management, but have stricter procedures. Continuous integration is performed by an important number of companies.

Architecting a system need a wide knowledge of technologies, COTS, projects, standards....