Vanguard Coder

Agile development processes are practiced either at grassroots where all people in the organization or sub-group play an active part in improving, following practices, and contributing to the processes. The alternative is to do what everyone else is doing (Drone-driven-development), or resisting change and sticking with age old practices, tools, and thus development speed, and user feedback and cycles.

Using job aggregation websites and forums, I analysed the quality of jobs, and requirements in UK, UAE, India – primarily because I know people working in these countries and the time spent to research each country  is large. If anyone want to help me in refining the criteria and and expand the list of countries, I’m more than happy to work together.

The criteria is:

1. Number of development (C#/Java) jobs posted requiring Agile developmental skills.

2. I also include how many SAP jobs exist to see industry focus.

I’ll exclude personal feedback from developers as maintaining some manual systems e.g. zipfiles instead of SVN, and QAs that only do manual testing.

Normalised Agile ranking:

UK – 100          (40% of all jobs are agile), C#/Java market share – 70% vs SAP. C#/Java are equally spread.

UAE – 12          (5% jobs are agile), C#/Java market share – 10%  vs SAP.

India -  37      (15% jobs are agile), Java/C# market share 70% vs SAP. Heavy skew towards Java

Conclusions:

UK is in an ideal position to focus on true  innovation and development and lead the way for others to follow. Not being platform specific they can exploit newer innovations rather than rely on vendor to supply approve supported modules and changes.

UAE is a SAP based economy. With C#/Java holding a very small proportion of the economy compared with SAP, and of the C#/Java jobs, a miniscule have agile listed as their requirements. UAE is likely to rely entirely on vendor products and development abroad rather than innovate and develop locally. This is likely to be the more expensive way in the long run, but the premium is noticeable.

India, like UK has a high number of C#/Java jobs as compared to SAP. However, Java holds a significant market share.

My thoughts:

I’ve generally seen companies eventually isolate and remove SAP, and other large systems as it’s expensive and fewer developers are are available, and consultants are required to maintain them which become more expensive as the technology gets out of date. There has been some effort to enhance SAP, however, it is a follower rather than a leader when it comes to innovation.

Joel did some excellent work in helping evaluate if we’re quiet there yet or not in terms of the inefficiencies we face during development and how much hair pulling needs to be done to just write code. Twelve years on with “Agile” being attempted it’s worth a review.

Working as a consultant, and talking with other developers,the attitude to development is “You can’t make an Omelette without killing a few people”, so the general approach many developers follow is just follow the process and get on with it. But it’s worth checking where you stand. It’s definitely more concrete than the Drake Equation.

I wouldn’t be surprised if this needs review in a few years with practices being adopted and standardized depending on the size of the company and the developer community in that area.

Data is a vital aspect of testing that we do, be it functional tests or unit tests. However, a lot of times in software development the data is “estimated” and not necessarily well defined. Eventually when going to deployment and the existing data which needs to be migrated is about to be  transferred, the team discovered to the horror that the data is slightly different – this could range from missing data to repeating of key columns. As a result last minute modifications are made and minimally tested before being deployed and hoping for the best.

So if it works, that’s great! But an earlier test deployment generally helps avoid this risk, or delaying the release until the data is ready (the system can’t be used if there is no data after all).

Biztalk is perhaps the most interesting product implemented by Microsoft. I’ve personally worked on many projects involving Biztalk. In many, I introduced and integrated Biztalk, in others, I implemented replacement for parts of it.

Problems primarily range from stability, finding people who know it at least to the level where Biztalk databases is corrupt, or loosing messages, and trying to look at the deep dark internals to find out where things went wrong.

Companies are sold Biztalk through slick offerings and presentations showing how simple and great it is from the business perspective, along with success stories such as in Thetrainline.com by Cap Gemini and Pershing by Microsoft . However, there are no follow-up stories if Biztalk is continued to be used, expanded, frozen or decommissioned after a few months or a few years of use.

Some companies eventually find less value, however, others fight to keep it in by looking for Biztalk experts that know how to firefight, or create roles such as Biztalk Lead (so leading a team of Biztalk developers?) – which might be trying to patch issues with the software rather than fixing them. This generally happens in large public bodies in small countries where the HR is centralized, but is not necessarily limited to it.

Biztalk is considered as a bloatware by a lot of Developers (not all), and there isn’t a shortage of companies adopting and removing Biztalk, and looking for viable alternatives. A blog by Biztalk MVP is an interesting read, and if adopting Biztalk, or getting rid of it, a question asked on stackoverflow was interesting as well.

Biztalk isn’t the only product going down this route. If the product offers drag and drop development to a certain extent, it’s worth having a second look.

If we’re being honest, I think a lot of us would like to continue to be developers, learn and invest ways in making coding efficient, quick, maintainable, and flexible. In essence, we’d like to remain forever young. However, time flows in one direction. And the tracks we leave behind get etched in what we do and write. I still remember the first team I worked with, the first interview, the first code review. They’ve left their mark.

As a Developer, I’ve always believed in the power of technology. But it’s a mean and not and end in itself. And coding and automation may not always be the only solution. A strong skills in analysis, project management, and being able to research the best solution and architect-ing a solid design are all just as vital but are sadly left out in most of the evaluation processes.

As a consultant it always puts things in perspective to deliver a working evolving system whether it is a throw-away application to be used for a year, or something that will remain a core part of the system 20 years later, it is the question of what is the best system and solution to what I’m being asked to deliver.

As books on C#5.0 (using .Net 4.5 framework) are being released, I remember during the pre-.Net 4.0 dates the awesome amounts of gymnastics that were done around the simplest design pattern – the Singleton.
Some involved double checking (in and outside the lock), setting up Memory Barriers. Most of this discussion can be read here. Finally System.Lazy came about and the rest was history.

I wonder wonder what’ll the most popular feature in that C#5.0 uses with .Net 4.5

public sealed class IrritatingConstructor
{
    private static readonly Lazy<IrritatingConstructor> lazy =
        new Lazy<IrritatingConstructor>(() => new IrritatingConstructor());

    public static IrritatingConstructor Instance
    {
        get
        {
            return lazy.Value;
        }
    }

    private IrritatingConstructor()
    {
    }
}

With time in some code bases containing a mixture of old code over a decade may end up with a lot of files and thousands of unit tests. The project may not have been refactored and a lot of technical debt has built up. Visual Studio may start of complain and give Out Of Memory Exception and not run your unit tests. A quick fix is to add a registry entry as pointed out here.

Add the following entry: HKLM\Software\Microsoft\VisualStudio\9.0\EnterpriseTools\QualityTools\EnableCMI = 0 (DWORD)

This will turn off auto discovery of unit tests, so compiling after changing unit test names or added new tests will be required.

Not a perfect fix, but something to keep you going for longer when you don’t have any other option.

I came across a post about pennies in the process which reminded me of some of the high-ceremony estimation sessions that I’ve been to that seem to run days, and not everyone is utilized, and some in which I had to come up with estimation on my own with some consultation with other people in development.

Canada is planning to get rid of pennies. I went to Lebanon recently, where there is no concept of pennies. A few other countries are going down that route as well – primarily due to inflation where the purchasing power has been eroded, and to manage them becomes expensive.

Having read a brochure by GreySpark, it reminds me of the the process drag created which elongate the project such as filling out forms at the end of the different stages (which no one reads, and is only there due to the process), not considering non-functional requirements, or working on slow-dated machines, and large solutions with many projects which cause development time and the learning curve to increase. Using tools such as Resharper save a lot of  typing time, makes running tests quicker (compared to what Visual Studios provides for MSTests). Avoiding creating custom frameworks, or solving small problems which have already been solved is also useful (e.g. ConcurrentDictionary in C# for storing values with its AddOrUpdate method, System.Lazy for singletons, an using (P)LINQ rather than writing loops are .Net 4.0 code specific examples).

Most interviews follow the process of:

• CV Review
• Phone Interview
• Code Challenge
• In-Person Interview
• Management/HR Interview.

Passing the code challenge is the easiest part which many developers seem to fall down on. Unfortunately, they take 4-8 hours to do depending on the level of Unit tests you do. This requires a lot of investment in time and effort.

The quickest way to pass is:

1. Use a factory to create different objects (Vehicles, vouchers, etc..)

2. Inject the Algorithm which does the calculation

3. In testing, use mock objects for this algorithm

4. Create a readme about your thoughts, and what could be improved in the code. This is beneficial as the code will be reviewed by someone whose opinion will sway based on the readme.

And that’s it. You’ve demonstrated use of patterns, unit testing and mocking, and will make it to the next round.