Are we solving the real problem?

Monday, June 25, 2007

Yet another reason to practice TDD - joeyDotNet

This is a great article that discusses the pros/cons of TDD, non TDD.



Yet another reason to practice TDD - joeyDotNet

Yet another reason to practice TDD

Things have been a little slow on the blog lately because this week is the start of a new job/company for me. I'm still getting a feel for things and of course one of the first things I'm trying to get folks interested in is TDD. I have a usual list of advantages and points that I use for getting across to folks the benefits of practicing TDD. Most of which center around the fact that TDD is primarily a design tool, and the fact that you get a nice set of automated regression tests is just a nice side effect. TDD is not about testing!

But today, after looking at some existing code, I thought of another example that does explain one way in which the "Test" part of TDD is very beneficial.

(For you fellow experienced TDD practitioners, this will be very obvious to you. So this is mainly for those who are still struggling with "why do I need TDD/Unit Testing?"...)




Powered by ScribeFire.

Tuesday, June 12, 2007

Embrace change, your life depends on it

Embrace change, your life depends on it: "Let me first start by warning you that this is a fairly long post. I suspect most people won’t make it to the end. However, if you are serious about being happy, I hope you can at least spend 5 mins reading what I have written.

It will change your life. I promise.

I have been an independent software contractor for several years, performing all sorts of IT development services for clients about town. The agency whom I have been representing at client sites is currently undergoing a major change - they have just been sold to a big consultancy.

Boom! Scary!

As a result of the merger, lots of change is happening. Some folks are questioning where things are headed, what management have planned, how their lives will change etc. Most certainly, there will be job losses as the two companies consolidate things, in particular administrative positions.

With the chaos that’s been unfolding, I’ve thought a bit about “change” in general. What is it? Why do people resist it? Is it always a good thing? What should I do?

With some reflection, I realised that with all inspiration, creation, thought and progress, some form of change must be a precursor. Things just don’t happen on their own. You know the old scientific principle of “energy cannot be "

Wednesday, June 06, 2007

StarUML - The Open Source UML/MDA Platform

StarUML - The Open Source UML/MDA Platform

StarUML - The Open Source UML/MDA Platform
StarUML is an open source project to develop fast, flexible, extensible, featureful, and freely-available UML/MDA platform running on Win32 platform. The goal of the StarUML project is to build a software modeling tool and also platform that is a compelling replacement of commercial UML tools such as Rational Rose, Together and so on.

* UML 2.0 : UML is continuously expanding standard managed by OMG(Object Management Group). Recently, UML 2.0 is released and StarUML support UML 2.0 and will support lastest UML standard.
* MDA (Model Driven Architecture) : MDA is a new technology introduced by OMG. To get advantages of MDA, software modeling tool should support many customization variables. StarUML is designed to support MDA and provides many customization variables like as UML profile, Approach, Model Framework, NX(notation extension), MDA code and document template and so on. They will help you fitting tool into your organizational cultures, processes, and projects.
* Plug-in Architecture : Many users require more and more functionalities to software modeling tools. To meet the requirements, the tool must have well-defined plug-in platform. StarUML provides simple and powerful plug-in architecture so anyone can develop plug-in modules in COM-compatible languages (C++, Delphi, C#, VB, ...)
* Usability : Usability is most important issue in software development. StarUML is implemented to provide many user-friend features such as Quick dialog, Keyboard manipulation, Diagram overview, etc.

StarUML is mostly written in Delphi. However, StarUML is multi-lingual project and not tied to specific programming language, so any programming languages can be used to develop StarUML. (for example, C/C++, Java, Visual Basic, Delphi, JScript, VBScript, C#, VB.NET, ...)

Friday, May 25, 2007

AGILE IN ACTION: Constructive disruption and compromised agility

I found this an interesting read during my regular blog reads. good on you Simon.

VALUE
IF you don't repeatedly release software
into a production environment
at least once every month
that realises business value
for a real customer...

QUALITY
IF you're not paying constant attention to technical excellence
with simple, effective, incremental design
driven by continuous, repeatable automated testing
with at least 95% coverage...

LEARNING
IF you're not learning
by inspecting and reflecting every iteration
and you're not re-planning, adapting and improving
all of the time based on what you've learnt...

TEAM
IF your team is not empowered to self-organise and be creative,
does not sit together and engage in face-to-face communication,
does not include your customer
and all the necessary skills to make its own decisions and take immediate action...

THEN YOU HAVE COMPROMISED YOUR AGILITY

AGILE IN ACTION: Constructive disruption and compromised agility

Thursday, January 25, 2007

IT on course to become a profession, says BCS - 24/Jan/2007 - ComputerWeekly.com

IT on course to become a profession, says BCS - 24/Jan/2007 - ComputerWeekly.com: "IT is on the way to becoming a profession with the same ethical and professional standards as medicine and the law, MPs and IT practitioners heard recently."

Very good article that makes IT people like myself feel a bit more special :-)

Would be good to see similar avenues in Australia. Perhaps the ACS are already addressing this.

Saturday, January 06, 2007

The Positivity Blog

I have a lot of feeds in Google Reader, most worth a read, but one that I always keep a look out for is the Positivity Blog.

Some great stuff here from Henrik Edberg, a 26 yr old from Sweden. He is not a specialist, like a pyshologist, just an enthusiast who collects and shares information on how to be positive.

Healthy mind, healthy person....

Saturday, November 11, 2006

Acceptance Testing and Continuous Integration

Company X currently runs a very agile development team, developing a system in java, very TDD, continuous integration (cruise) ... you get the picture.

They also have a dedicated test team, very impressive. Of that team, one group called "QA" who are essentially responsible for black-box testing and are very knowledgeable in the business process - they are very close to the user-base. In fact they report directly to the business, in contrast to the developers who report to Technology.

Another test group is responsible for white-box testing. These guys are trained developers but their sole purpose in life (thats going a bit far) is to break the system from the perspective of getting under the bonnet and tinkering, pouring oil in the radiator and mistakenly jamming a potato in the exhaust pipe. Then sit back, wait, see what blows up. Then run up to the developers and say "Come take a look at this!!!".

I hope you appreciate me painting the picture here, it will mean something later.

The main message behind this post is a nagging problem with our continuous integration, running on cruise, I will refer to it as Cruise for simplicity although this problem should occur on other CI systems. As I arrived on the project when it was already in full swing (I estimate 18 mths had already elapsed), a lot of the architecture, toolset, build scripts, tests are already well established - perhaps looking a bit shabby now, but were probably a great idea 2 yrs ago. One of the most annoying problems with Cruise is the length of time to build - ages it seems and nearing unacceptable. The system architecture is split as Common, Management, Capture and is built as such. In total I estimate 70mins to do a full build of all 3 subsytems.

The question I pose here is should the black-box and white-box tests be run on every Cruise build cycle? My gut says, no. I think it is always a case-by-case basis depending on the running time and urgency. For this site I describe I think they should run at least at the end of the day.

I would be interested in hearing comments.