Developer User Group 2014 Survey results

Submitted by Robert MacLean on Thu, 04/24/2014 - 21:01

This year we launched the first annual user group and let me say thank you to every single one of you for taking the time to help us improve the group. For this survey all questions were optional so you may see some differences in the numbers. This post is meant to share the data and I am not going to speculation about what this could mean or how we will adjust the group based on it at this point. Lets have a look at the data!


The final item in the survey is the first I want to discuss – the comments. Many where along the line of congratulations which is awesome but there are four I want to highlight here.

more code please, e.g. everyone has talked about 'everything must be unit tested', yet not once have i seen the actual code. I AM UNIT TESTING, BUT I FEEL THE COVERAGE IS NOT ENOUGH, SO IT WOULD BE HELPFUL TO HAVE A REAL LIFE EXAMPLE OF 100% COVERAGE REGARDING TEST DRIVEN DEVELOPMENT.

We will be having the awesome Martin Cronje in June doing a talk exactly on this! Another idea would be to attend the CodeRetreats where this is a major focus of the events. A personal comment based on the talks I have given; the time for a presenter is limited so if they are talking on SignalR adding unit tests not only takes time away from the talk but can also confuse the audience.

A suggestion to some of the discussions is to have a practical aspect where coders can code

I love the scenario where the audience can code with the talk but there are logistical reasons this doesn’t work well in our format. The presentation style is the one that works best.

Have more advice for novice/beginners to programming

Below I will talk about what type of events we run most often, and while the bulk of our talks are technology focused which can be very tough for novices we have a big chunk that are about methodologies, theories, stories and patterns. These are PERFECT for a novice since they share valuable information which doesn’t rely on technical understanding.

I haven't attended for some time due to other commitments, but for some time I thought it would be beneficial to have a bit more conversation / talks about the open-source languages and projects. I understand that the group was initially primarily started around Microsoft products, and that's great, but in my field open-source is more dominant. It's just an observation, though, nothing against the setup of the group per sé

I disagree with this view – having a look at our past events the break down of the sessions is as follows:


Looking at the numbers – we are more about open source technology and developer improvement than Microsoft.

Overall, how satisfied or dissatisfied are you with the Developer User Group?

The first and most important was how satisfied or dissatisfied people are, on a scale from 1 to 5 (1 being bad – 5 being great) and we hit at an average of just over 4! Smile

How likely are you to recommend the Developer User Group?

Second is very important for us, because we want to grow the group and being recommended is the best way for that. Here we did a scale from 1 to 5 and did even better scoring over 4.4!

Overall, how do you find the complexity of the sessions?

Third is  how members are finding the content – with this also on a 1 to 5 scale with 1 being too simplistic content and 5 being too complex content. 3 is the just right spot and we came in almost exactly at that!


Start time

imageThe most discussed issue in the group is the start time – it is brought up almost every month in the comments. Keeping the time the same really smashed the other options, both individually and if you group the times into early (16h00 + 16h30), medium (17h00 + 17h30) and late (18h00 + 18h30). We are planning to use the early start time to allow for longer sessions with multiple topics going forward so hopefully that will enable people to get the best of both worlds.

  • Keep it at 16h30: 49%
  • Start earlier at 16h00: 6%
  • Start later at 17h00: 15%
  • Start later at 17h30: 10%
  • Start later at 18h00: 15%
  • Start (really) later at 18h30: 5%

What do you hope to gain from the developer user group?

imageThe only item to allow multiple options to be selected, is also one of the most important – what do you want? Almost everyone said learning new skills and networking.

  • To learn new skills: 95%
  • Networking with other developers: 93%
  • Free drinks & pizza: 37%
  • To find potential employees: 20%
  • To find a new job: 12%


imageMoving into the demographics for the group – the first one is age with the majority between 26 – 35.

  • 26 – 35: 75%
  • 36 – 50: 16% 
  • 18 – 25: 6% 
  • 51 – 65: 1% 

What is your level?

imageThe next item is the level, which shows a strong slant to the senior level.

  • Senior: 70%
  • Intermediate: 22%
  • Junior: 6%

What is your primary programming language?

imageThe third demographic which is vital for us in planning content is around primary development language and we have a GREAT mix of languages but the strongest community is c#.

  • C#: 59% 
  • Java: 9% 
  • C++: 3% 
  • JavaScript: 4%
  • Visual Basic: 1% 
  • I'm a QA: 1%
  • Python: 1%
  • PHP: 1%
  • Objective C: 1%
  • SQL: 1%
  • Many of the above: 1%
  • Scala: 1%
  • I'm a novice wanting to learn: 1%
  • Project management: 1%

What is your primary type of development work?

imageIn line with  planning content, knowing what people are doing is vital. Web work (internal and external) is a strong lead followed by integration and mobile.

  • Mobile apps: 11% 
  • Internal web sites or Intranets: 30% 
  • Integration projects: 19% 
  • External/Public web sites: 27% 
  • Coaching: 1%
  • UI/DB/Platform: 1%
  • Many of the above: 1%
  • Internal Projects: 1%
  • I'm a Novice wanting to learn: 1%
  • Server side development: 1%
  • Data warehousing: 1%

Organisation size

imageHow big are the companies that developers come from? Here it looks like a strong split between small (less than 20) and large (more than 90). Which I think is pretty accurate for the industry as a whole in South Africa.

  • >200: 25% 
  • 11-20: 8% 
  • 1-10: 29% 
  • 21-40: 12% 
  • 91-200: 14% 
  • 41-80: 9% 

Role in purchasing?

imageFinally, a question we can use when discussing with sponsors is what role people have in purchasing. Here there is some influence or none.

  • None: 37% 
  • I can suggest/influence purchases: 51% 
  • I make the final say: 11%

Raw data?

Want the raw data – you can download it below.

Rangers Treasure Map v2.1: Snap re-invented

ScreenGrab (1)As part of my work on the Microsoft ALM Rangers Treasure Map, I want to share about how we changed snap for the 2.1 release.


The first question, is why do we need to change snap for 2.1? The requirement is that 2.1 is primarily focused on supporting Windows 8.1 & Windows 8.1 does snap a little differently to how Windows 8 handled snap. In short, in Windows 8 you had snap (fixed width), a full screen and third “middle” state – however Windows 8.1, has full screen and then any value between that down to a minimum width.

ScreenGrab (2)Microsoft has written a great document covering what is new at:


Step one in doing this was to investigate what we had – so I just took the app and ran it on Windows 8.1 and played with the new snap experience. From that I took screenshots, made annotations etc… for us to decide on an approach. You can see these images along the side/bottom of this post.


ScreenGrab (3)Since this is a minor release for us, the decision to not invest too much into this release was made. So we decided not to try and build something brand new but rather make sure everything works as it does currently.

To this we chose a minimum of 320 pixels (the default in 8.1 is 500) since that matched what we had in Windows  8.


One of the choices we made in version 1, was to NOT use the out of the box state manager way to change the UI. You can find out more about how we implemented that in a video I did for Channel 9ScreenGrab (4):

ScreenGrab (5)

So what did the code changes look like for with our model? In the image below you can see that rather than ask what state we are in (line 142 on the left) we rather just check the screen width and based on that we load the correct namespace.

This tiny change was all that was needed, and this was made successful because we decoupled the views from the start rather than trying to have one view that does everything using the visual state manager.


Robert MacLean Wed, 10/09/2013 - 11:54

Scrum, it is just shorter waterfall?

Submitted by Robert MacLean on Tue, 10/08/2013 - 10:30

When I speak to people about Scrum, I often hear people describe Scrum as: Waterfall but with shorter iterations. That view, imho, is fundamentally wrong and will lead to you not getting any of the benefits from using Scrum.

Waterfall Myths

imageWaterfall provides a structured approach to software development and has a reputation for taking a long time to deliver because each phase must occur and must occur in order. In reality Scrum is very similar and has many of the same steps, in the same order as Waterfall.

So what about the length of time issue? Waterfall seems to be used around massive projects which takes months or years to ship, yet Scrum is great because you have a minimum viable product (mvp) every four weeks. That isn’t true either – a lot of the myth here is because during the scoping of a project using Waterfall, everyone puts the everything in. In reality, nothing stops you having smaller deliverables of a mvp while using Waterfall.

The last myth to dispel is that Scrum is better than Waterfall because it allows the product owner to change the goals as they learn about what is built & the market conditions change. Waterfall does allow that too. In Waterfall it is called change controls and, done right, they work very well.

In addition, if you use smaller iterations with Waterfall, you can use the requirements, design & verification stages as you would sprint planning & retrospectives to adjust the course of the team.

How is Scrum different to Waterfall?

A side thought, is that difference in that ownership could also be why projects using Waterfall seems to fail more than those using Scrum. It isn’t the methodology but rather it is the people doing the work’s commitment which drives the success or failure of the project. For projects using Waterfall where they are successful, I think you will find that they do many things outside the methodology to ensure everyone feels committed to the success.

If Waterfall can offer everything that Scrum does too, how then is Scrum different? The major difference with the two methodologies is around the psychology of the developers involved with the project:

  • Waterfall: Have a single centralised, ownership for the project
  • Scrum: Have a distributed, ownership for the project

That may not make much sense, so let me explain what I mean by ownership of the project. The ownership for the project is made up of a number of things:

  • How much responsibility a person involved has?
  • How much authority a person involved has?
  • How much control and influence a person involved has?

When we look at Waterfall, the developers involved in the project have very little with regards to the above conditions. Those conditions are almost solely handled by the project head and project managers, and because of this lack of authority, responsibility and influence the developers are not invested in the ultimate delivery of the project.

Scrum on the other hand, drives verifying levels of responsibility, authority and influence to everyone involved. For example the product owner has the most responsibility but there is still responsibility shared to the rest of the team. It is impossible in scrum for a developer to bury their head in the sand and say the problems are not their problem.


scrum-pigs-chickensFor me the major difference can easily be summarised using the old fable of The Chicken and the Pig. Waterfall allows developers to be chickens but scrum requires the developers to be pigs.

Choosing between Waterfall and Scrum isn't so much about choosing between methodologies as choosing between designs of ownership and responsibility. That design is vital because how your team is designed directly impacts what you ship.

LightSwitch: Passing data between screens - Example 5: Passing information to an "add" screen

Submitted by Robert MacLean on Tue, 09/24/2013 - 13:19

For other posts in this series, see our series list.

In the previous examples, we have always passed data to a simple browse screen. Passing to a screen where you add an item is a little more complex so we will look at how to solve that. It may also seem that what we did in example 3, wasn’t useful since example 4 showed a better way – however there are times you can’t do that so we will also look at that. Finally we will end with a better way to do this, using a b

This posts, and the rest in the series will be a bit shorter as we are covering the same theme but applied in different ways – so make sure you read the preceding parts or you may feel a bit lost.

As with each part of this series, the code can be found on GitHub.

Example 5a: Passing information to an “add” screen with JavaScript

1. On our add screen we start by adding a data item. We will name it Animal and we will set the Type to Integer. The point of using Integer is to show that the type of the property doesn’t matter to JavaScript. Setting it to a different type than we expect, only affects the tooling.  Lastly we set this to be a parameter.


2. Now we will do the code for the create event, and here we need to do two things. As this is a “add” screen, the first bit of code is to make sure we have an object defined. AnimalInfo is the object that the screen monitors and will persist to the backend – so if it is not defined (null) we must create our own.  We do that with:

if (screen.AnimalInfo == null){<br>&nbsp;&nbsp;&nbsp; screen.AnimalInfo = new myapp.AnimalInfo(); <br>}

And then we follow that up with the simple line of of assigning the name of the animal from our data item: screen.AnimalInfo.AnimalName = screen.Animal;

Note: even though we set the property which is of type string, to an integer – it just works.


3. I mentioned the tooling becomes a problem if we do not use the right types, so to see how that occurs – we add a button to the browse screen (that we used in the last example) and try to open it up our screen and set the name, however Visual Studio doesn’t let us.


4. We can just work around this in code, and we start off on the browse screen by adding a button with the method named ShowAnimalInfo


5. The code we use in the button is very simple: myapp.showAddAdnimalInfo(null, screen.AnimalsSet.selectedItem.Name);

This should look very similar to example 4, except we have a null in the first parameter (since we want the add screen to create the object associated with the screen – which we covered in step 2). The second parameter is passing the selected items name to the screen. Once again, the tooling is expecting an integer but JavaScript is dynamic so it will accept a string.


6. That’s it! It all just works!

Example 5b: Passing information to an “add” screen – working with the tooling

This final example, is to show you just how nice the tooling is when you pass the right types around and how you can do the same as above without JavaScript. If you are looking at the demo code, this is in the AddAnimalsInfoSmart screen.

1. The major different here is the type of the data item we add as a parameter. So for this we set the type to the Animals (Entity).


2. Now we need to write a bit of code again on the create event. Since we are only going to use the tooling to launch this screen, we do not need the check to see if the object for the screen is set. All we need to do is set the values.


3. Finally the button on the browse screen is just added using VS without JavaScript & we can use the IntelliSense to select the right things:


This second route is WAY better and what I recommend using, but it is great to know if you find yourself in a situation with two types that don’t match up you can work around it with a trivial amount of code.

LightSwitch: Passing data between screens - Example 4: Passing a database item without JavaScript

Submitted by Robert MacLean on Fri, 09/20/2013 - 15:43

For other posts in this series, see our series list.

In our last example, we passed data from one screen to another using a bit of JavaScript. However there is two issues:

  • If you do not select an item before clicking the button – it errors
  • It needs code, and LightSwitch is about making the drudge work easier so how can it help here?

This posts, and the rest in the series will be a bit shorter as we are covering the same theme but applied in different ways – so make sure you read the preceding parts or you may feel a bit lost.

As with each part of this series, the code can be found on GitHub.

Example 4: Passing a database item without JavaScript

1. On the BrowseAnimals screen we already have, we once again add a button to the screen in the command bar with the following properties:

  • Choose an existing method: showWeasel
  • data: AnimalsSet.selectedItem.Name

What we are doing here, is having the Weasel screen shown & because we added a parameter we can use the build in tools to set that parameter to a data item on the screen.


(in the above image the parameter is labelled myData – for our example it will be data).

This is it! It is far simpler than example 3, it also doesn’t have the issues we mentioned at the start – so you should always use this option if you can.

LightSwitch: Passing data between screens - Example 3: Passing a database item with JavaScript

Submitted by Robert MacLean on Wed, 09/18/2013 - 23:39

For other posts in this series, see our series list.

In the first example we looked at the core concept behind passing data and we followed that by understanding the power that having a dynamic language in LightSwitch offers us. In both examples, we passed a string we hard coded – what about if we want to pass something from our database layer?

This posts, and the rest in the series will be a bit shorter as we are covering the same theme but applied in different ways – so make sure you read the preceding parts or you may feel a bit lost.

As with each part of this series, the code can be found on GitHub.

Example 3: Passing a database item with JavaScript

1. We start off by creating a table, Animals which just had a Name column for the name of the animal we will capture. 


2. Next we will create a simple screen to add an animal and a second screen to browse the list of animals.

3. On the new Animals browse screen we will add a button named ShowWeaselCodeWay – the idea here is you will select an animal from the list of animals and click the button. That will launch the same Weasel screen from part 1. For this example I am adding it to the command bar.


4. Next we need to edit the code to pass the parameter – so we use the execute event again and put in:


The only new code we are seeing here is the screen.AnimalsSet.selectedItem.Name part – which is as it sounds: for this screen, give the AnimalsSet data item (which powers the list), then give me the selectedItem in that and lastly, give me the Name property of the selected item.


That’s it! Nice and simple, but not without it’s issues – which we will discuss & solve in the fourth example.

LightSwitch: Passing data between screens - Example 2: Passing an object and avoiding ugly global variables

Submitted by Robert MacLean on Tue, 09/17/2013 - 20:44

For other posts in this series, see our series list.

In part 1, we did the simplest solution – passing a string to a screen. In this post, we will do two changes on the same idea.

As with each part of this series, the code can be found on GitHub.

Example 2: Passing a objects and avoiding ugly global variables

The core to learn in this example is that JavaScript is a dynamic language – it is FUNDERMENTALLY different to a static language like C# and those differences allow us produce much cleaner code.

1. We start off again, with a button which we will name Crackle.


2. We will also create a new screen, named Rice. On the new screen add a data item with the following properties:

  • Screen Member Type: Local Property
  • Type: String
  • Is Required: True
  • Name: data


3. And, the important part, we change the data item we added, named data, properties and set it to be a parameter.


4. So that we have a way to see the data, we will use a custom control again – with it’s data set to Screen. We are not renaming this new custom control – so it will be named ScreenContent. We can see this on the property pane of the custom control.


5. Next we add some code to the create event for the new screen:  screen.findContentItem(“ScreenContent”).tag =;

Let’s break that code down:

  • screen.findContentItem(“ScreenContent”) – this method allows you find a control on the screen by passing in the controls name. So here we pass in the control we added in step 4 and that method returns it.
  • .tag – here is the first example of using JavaScript as a dynamic language. The custom control doesn’t have a property named tag, but since we referenced the property, it gets added.
  • – here we are referencing the parameter we added back in step 3.

Using the tag here, allows us to pass data to the control that needs it without the global variable in the first example.

6. Now on to the code to do the rendering of the data. Rather than just using a simple string, as in example one, I want to use a object with properties. The code for that:

var data = contentItem.tag;

element.innerText = “first name” + data.firstname;

If we break that code down, we access the tag property of the control (here passed as the parameter contentItem) which we created in step 5 above. We assign the value of that to a variable named data. Note: this isn’t the same data as the data item we created in step 2.

Next we set the innerText of our control, so it renders something, and we access the property firstname from our new variable.


7. Last we need to launch the screen, so we go back to the button we created in step 1 and edit the execute code for it. The code we add there is: myapp.showRice({ firstname: “Robert”, surname: “MacLean” });

This is the same as the last example, except we are passing in an object with two properties. This highlights the dynamic nature of the JavaScript again because you will remember this is “defined” as a string but we pass in a object which is perfectly legit code in JavaScript, and because this is a real object we can access the properties for the rendering in step 6. This is different from the inheritance we are used to in static languages where you cast objects – this is actually changing the type.


All done!


LightSwitch: Passing data between screens - Example 1: Passing a string

Submitted by Robert MacLean on Mon, 09/16/2013 - 22:02

For other posts in this series, see our series list.

Recently I saw a question about how you can pass data between screens, which is something we do a lot of in our system – so I thought I would share details on how we do it. There is a number of ways to do this, so we will start this series with a simple way of passing a string.

As with each part of this series, the code can be found on GitHub.

Example 1: Passing a string

1. For the first example what we will do is pass a hard coded string from a button on screen to a second screen. We start off by adding a button (called Pop) to a screen.


2. We then create a screen for it, in our example the screen is called Weasel.


3. On the new screen we add a custom control and set the data to be Screen.


4. The core of this method is first to add a new data item. For this example we will specify it as follows

  • Screen Member Type: Local Property
  • Type: String
  • Is Required: True
  • Name: data


5. After you click OK, click on the data item in the right hand side and go to the properties and tick the check box: Is Parameter


6. For the execute event for the Pop button we add the following code: myapp.showWeasel(“pop goes the weasel”);

We are using the out of the box JavaScript here to launch the code, but if you have never done this before let us look into what that simple line has:

  • myapp: This is the namespace for our app. This is the same in every LightSwitch app.
  • showWeasel: This is the method to launch the window. LightSwitch uses the pattern of show followed by the screen name.
  • “pop…”: This is the data we want to pass across. We get this property on the method as we created the data item above and set it to be a parameter.


7. Finally we just need to show the string on the Weasel screen. To do that we need to add two events – first we will add the created event for the screen. The code we add here is to first put a variable outside the event (named d) and then in the event we add the following: d =;

In short, when the screen is created, we read the data property from the screen and set a global variable d to be that result.


8. Secondly, we select the custom control we added in step 3 and edit its render code.

In the render code we just set element.innerText = d;

This just renders the string, it isn’t important for passing the data other than to show what we got.


9. The final code will look like the following. One note, in the example below, it says screen.myData – but that should be as out data item is named data.


And that’s it! That is how to pass a simple string.


LightSwitch: Passing data between screens - Series List

Submitted by Robert MacLean on Mon, 09/16/2013 - 21:59

This page is used to list the parts of my series on how to pass data between screens. Some of these aren’t up yet, so they are not linked. As soon as they are available they will be linked here!

As with all post in this series, you can get the code for this from GitHub.

Creating Web Pages Using the LightSwitch HTML Client in Visual Studio 2012

Submitted by Robert MacLean on Mon, 09/16/2013 - 21:12

imageMy friend and fellow MVP Michael Washington runs THE LightSwitch website, and recently he published a book, Creating Web Pages Using the LightSwitch HTML Client in Visual Studio 2012, with and I decided to buy a physical copy to show my apparition of his great work. I thought I would take some time to write a brief review of thebook.

The question I always ask for a review, is this the book for me – the answer is YES! This book is for EVERYONE! However, let us dig into some more details on the book.

Newbies to LightSwitch

If you are new to LightSwitch, or new to the HTML client, then the book covers a lot of the things you need to think of. Each chapter covers in a very practical way how to implement what it showing and it is very visual in how it covers the material. What is great is this book doesn’t shy away from the developer aspects, and there is plenty of coverage on the JavaScript development models and how to put it together.

This is so good for newbies, that I think Michael should license this to Microsoft so they can build training material around it!

LightSwitch Professionals

I have done LightSwitch for years from the smallest projects to massive things and everything in between – and even I saw & learnt things. A lot of what I personally gain was ideas of how to put content together and ideas on JavaScript libraries. I literally went to work the next day after the book, and submitted a list of ideas inspired by the book!

Where the book is weak

The book isn’t perfect though – where it falls down is the later bits, most glaringly a section on using a WCF RIA Service with it. RIA Services, with the death zombie-ness of Silverlight (in my view) and LightSwitch does support WebAPI which is what ASP.NET is pushing & is the future (in my view) & there is no Web API material. 

The only other problem, is that the images are in grey scale. While reading it didn’t annoy me but when I closed it, and realised the final example image is the image on cover… I realised how much I lost not having colour images.