Tuesday, 25 November 2014

Agile vs Waterfall and Other Snake-Oil Vendors

Agile development is sometimes "sold" by companies and individuals as being the answer to the problems of software development using Waterfall. After all, we all know that before Agile, Waterfall was what everyone used and some companies still use Waterfall.

That's not actually true.

No company I know of has ever used a Waterfall methodology in software development. All software development has always been Agile in some form or another, even before the original manifesto.

The Waterfall method originated from manufacturing where each step is defined and changing the design half way through is prohibitive.

I’ll quote Wikipedia here:

The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce, although Royce did not use the term "waterfall" in that article. Royce presented this model as an example of a flawed, non-working model.

So get that – There never was a software development methodology called "Waterfall", it’s a manufacturing and construction process used in an article in 1970 to show how it couldn't work with software.

Friday, 16 May 2014

Why Delphi and why now?

I've just recently finished up a great contract with a Regional Council, as their Development Team Leader for a great team of developers and business analysts. It was a fun role and it got me to thinking more and more about my pure love for developing great applications.

Those who have been following my blogs and career have seen that I have moved more and more into leadership, and management over the last 10 years. This has been a very enjoyable time, and has taken me into areas that I never thought I’d have opportunities, but I still missed the code.

There’s something special about helping teams to be their best; about making sure that management knows how productive the teams are; and helping others and seeing individuals grow within the teams. But in recent years, I've also realised the “something special” about being able to create.

I'm about to start another contract but this time as a Senior Developer. Now I know what you’re thinking already. I have been a development manager, a software group manager, and even a CIO; why would I want to take what can be perceived as a step back in my career?

I don’t see this as a step back at all. Actually, I see this as a return to what I love and what most drives me. As a team leader and a manager, I was one of many. Yes, I was able to deliver; I was able to make changes resulting in huge improvements; and I was able to assist many along their own career paths; however I was still just one of many. As a Senior Developer I became well known. I was sought after for my skills (let’s hope I still have some), and I made my mark. Through some serious navel gazing that has been ongoing for a few years now, I simply decided that being a developer was my core skill. Like all good management decisions, I decided it was time to focus on my core function.

So, I am very excited and not in the least apprehensive about taking the plunge again and returning to being a Senior Developer.

The company I am going to work the rest of this year for, uses Delphi for its core product development and during the interview stages, I was asked if they should change. Many others have suggested moving to Java or VB .NET. Some felt that C# was the way to go forward. It’s a very valid question and one they should not take lightly. I looked at both their product and their small team. I knew that my answer should be to move to .NET, but I could not think of a valid argument for that; I also knew that if it was a new product, I would be suggesting something like Ruby on Rails, but it's a stable product in daily use by tens of thousands of users who rely on the stability of the product. My eventual answer was that they should upgrade to Delphi XE6.

 

 Yes, I can hear the wails, the howls of indignation, and the gnashing of teeth out there but the team had used Delphi very successfully for more than 20 years (yes, the developers had been with that company for that long and longer), turning around and retraining in another language would require a good and reasonable result and damned if I could give the a single reason other than “it’s expected”.

Also, as I have said many times before, Delphi is a very productive language and changing languages may result in needing a larger team with reduced knowledge. Knowledge in the product itself may even be at risk as the current team may no longer enjoy the experience and move on.

No, Delphi was the answer no matter what others would say. With the recent release of Delphi XE6 they could seriously look at the tablet and smartphone markets as well as normal pure enhancements, all using a small, dedicated, and very experienced team.

So it’s back to being a developer for me and I couldn't be happier at the prospect.

Sunday, 23 June 2013

Programmer or Analyst Developer?

I know these terms to mean different things in different countries or even different organisations so I'll explain.

  • A Programmer is a person who is given a task and codes that task as it is described. Usually this task is described by a Business Analyst in the form of a Requirements Document or a User Story.
  • An Analyst Developer will speak to the users to help define what their need is, then code that need.


I had an interesting talk the other day with a Software Development Manager who was looking at the whole idea of the Business Analyst that so prevails our thinking around software development. A number of years ago there was a push never to allow the programmers to talk to the users. The huge push for Business Analysts was on and the Analyst Developer idea disappeared from our vocabulary.

What this person was suggesting was to reintroduce that idea. He recognised that not every programmer was an analyst developer and there was still room for the programmer in the teams, but that instead of having a number of business analyst producing streams of paper and diagrams, this function was sometimes better produced by an analyst developer.

Thursday, 23 May 2013

Version 6 of Jira has been released

Atlassian has released Version 6 of its great Jira tool. I must admit to being a big fan of Jira from its infancy and have installed Jira in a number of organisations in New Zealand, the UK, Australia, and Germany.

See my previous post on a much earlier version of Jira - Tools for the Development Team - JIRA.

Atlassian has released a number of versions since that early review and its long overdue to do another review, but that's for another article.

So what's so different about Version 6?

There's a new user interface. Atlassian have recognised that while its second nature for long time users to make their way around Jira, it can sometimes be a learning curve for new users. This new user interface is designed to allow new users to get to know and use Jira that much faster and easier.

Sunday, 19 May 2013

Delphi, why won't it just die?

Over the years, I've programmed in a lot of different languages. Along the way, languages have come and gone in typical "Flavour of the Month" style, while others that have been predicted to be flavour of the month, have become very mainstream;  Java being one of them.

I used to do a lot of work in FoxPro and it was used extensively in almost every company and government department in New Zealand, but then Microsoft bought it and firmly placed its boot over its head knee deep in water and it slowly, desperately, died.  Even then it was flailing about so hard that Microsoft was forced to simply state, "No More FoxPro! Last version ever!"  in about 2007 despite having millions of followers.