Canberra Developer Blogs

These are the Canberra developer blogs that I have gathered so far. This list will be updated as I find more. Here is the list:

• Brian Farnhill blogs, speaks and knows about SharePoint;
• Dale Anderson writes The Ravings of a Software Engineer . He is the author of the Tribe platform;
• Pia Waugh is an open government and open data ninja who is freeing federal data;
• Rod Weir and his team produce software for helpdesk and support services;
• Manickam Ramanathan is a passionately curious .NET developer;
• Jeff Lau is a Java dev with good insights for all devs; and
• Damana Madden is me. I am a .NET developer with a tendency to code in lots of different non-Microsoft languages but C# has my heart.

Visual Studio Tricks - UML Validation of your Intended Architecture

Now for the third post from the series of Visual Studio Tools I Can't Live Without on using UML diagrams to validate your intended architecture.

Part of what I do when I run a code review is to extend it with a report on design divergence. That is when I look at what the intended application design was and what has actually been implemented.

This takes several long and probing interviews with the application architect or technical lead, asking questions about what they think has been coded. Then I look at the code at a high level, with more attention paid to sections with more complexity.

Sometimes it is pretty spot on. Sometimes it is very very different when we get in to the code.

As mentioned in other posts, I will use tools like dependency graphs to get a quick high level understanding of a code base. Another tool that Visual Studio gives me that I didn't have in the past is UML diagram validation of code.

Visual Studio has a project type called a Modelling Project that allows you to create different kinds of UML diagrams that communicate what your intended application design is or are created from code and show the implemented application design.

Again, there is a lot of documentation on how to create these diagrams. The main thing to know is that there are many different types of diagrams and once you put them in place, they can be used to validate the actual code.

Using these tools, you can reverse engineer a code base quite quickly and take in the high level design visually, which is for me the fastest way to understand an application architecture.

It is also quite revealing in that it can show boundary violations between components that cause future extensibility pain. In one case, we identified calls being made from the view directly to the data access layer, bypassing business logic layers. The architect there didn't realise that some of the less experienced developers didn't know they shouldn't do things like that.

Layer and Class diagrams are my favourites. The ability to drag and drop a file from the Solution Explorer in to the diagram makes them a breeze to create.

Once I have diagrams in place, I communicate to the technical leads how to continue to use and create them for regular checks and even in gated check-ins.

A picture really is worth a thousand words.

Visual Studio Tricks - Dependency Graphs

In the second post of this series of Visual Studio Tools I Can't Live Without are Dependency Graphs.

When I conduct a code review or set up a gated check-in, static code analysis will give a list of all the things that are wrong based on a predetermined set of recommended practices. These are mostly superficial and not 100% indicative of whether a code base is bad or terrible or should be burnt to the ground.

Usually, people will look at the number of of errors and warnings found by static analysis to draw conclusions. These can often be the same issue over and over due to things like copy and pasted code, generated code or agreed practices that counter recommended practices.

In any code review I carry out, there is more than just a list of errors. There is an understanding of where those errors sit in the the scheme of things, how serious they are and if they are an indication of worse things to come.

To draw theses kinds of damning or freeing conclusions, an engineer must understand the code base. We have only days to get to this point so we draw on everything we can to help us with understanding what we are judging.

Years of experience will help.
A walk-through with the technical lead will help.
And a picture that speaks a thousand words will certainly help.

With Visual Studio 2012 (VS2012), I have embraced and celebrated the idea of Dependency Graphs along with Analyzers.

There are a lot of instructive posts about how you go about this. There is no need for me to walk you through it.

What I do want to do is make you aware that there is a way to look at the complexity in code in a visual way. You can find and explore circular references, unreferenced nodes and hubs which are highly referenced nodes.

One place this is valuable is in code reviews of pending change sets. VS2012 can filter to just pending changes. This allows a technical lead to ensure that unnecessary complexity is not introduced with bug fixes or added features.

If you need to understand how your code is connected then use this tool. You may even become dependent.

Visual Studio Tricks - Code Clone Detection

It seems that the tools I take for granted are not used by all. This is the first in a series of posts where I will be sharing some of my essential Visual Studio tools that every .NET developer should be aware of. If you already are then avoid me stating the obvious and go read something else.

Call me Code Review Girl and hand me a cape. In my role, it is common for me to travel the depth and breadth of Asia, Australia and New Zealand to conduct a code review and design divergence checks on very large government and commercial code bases.

Microsoft has internal tools that let us do that with great ease. This is always where we start. However, we often go further with remediation plans and sit with developers to show them the kind of things we found in their code that need improving. We don't just show them how to fix it but explain why these issues are issues and how they can be tracked down. In my case, I use pair programming to start. Teach a dev to fish and all that.

When I pair program with a developer, I will never let them copy and paste code. They can either type the whole thing from scratch or they can write a method and call it in both places. Copy and pasting code is an anti-pattern that will result in bloated code bases and often carried errors.

Now, that is all well and good when you are writing new code with another developer but for the times when you aren't watching and enforcing that rigour or for past crimes, Visual Studio 2012 gives you Code Clone Detection.

I won't go in to too much detail repeating what the link above explains but I will give you a quick summary of what you get and how to use it.

Code Clone Detection looks at code statements of 10 or more lines that appear in methods and properties across entire projects or solutions. It works on code with up to 40% of its tokens changed and with statements that have been rearranged.

There are two ways to use it:

1. Highlight a specific piece of code, right-click and choose to Find Matching Clones in Solution; and find that specific code repeated; or
2. Use the Analyze menu to Analyze Solution for Code Clones and find all occurrences of repeated code.

There are ways to exclude certain files like generated code and you will want to do that with large generated code bases.

I find this one of the most useful tools when looking at how to attack a large code base that needs a refactoring machete. This is a tech lead's best friend. Or at least one of them.

Let the clone wars begin.

Have you heard of a magical place called the Internet?

I am a little bit of a spoiled brat when it comes to the wired world. My web presence started with Geocities when we embraced animated gifs and blinking HTML. Then I moved on to pimping MySpace in the mid-noughties and then discovered the pedestal that is having your own blog. Yes, I lived in the even older text based world of newsgroups and spent hours surfing the web with Lynx.

These days, I feel sad when I meet "IT people" who think they are somehow carrying a banner of normality by not being on Twitter or Facebook or LinkedIn. They ask "why would I want that?" and to be honest, I couldn't care less that they haven't worked out that the world is leaving them behind.

In fact, it shocks me to come across "computing people" who snigger at the idea of an online brand only to wonder why no one hires them based on all the silent good deeds they have done. I call that a home brand. Yet, they go on to tell me that the world is a meritocracy and no good deed goes unpunished. I don't snigger back.

In my job, I build bloody big web sites for super large companies. I build mobile line of business apps for multinationals. I build dumb games for smart phones. I talk about design of architecture and of user interface. I demand usability and an enjoyable user experience. I make interacting with the virtual world easier for people who don't spend their whole lives online like I do and for those who do.

It is unsettling to see the same mistakes being made over and over again. To watch cluttered interfaces be embraced by technologists who I think should know better. To see people tell me that this is the way the world is when I sit in their retro worlds and think of how young I once was when the thing they are championing was actually the new black.

In the past, I would try to educate them. Explain in detail the reasoning behind good design in visual ways and in code. It would take time and patience and not slapping them but I'd invest and finally help them understand the modern way.

I'm not even talking cutting edge. Just what is accepted now.

Everything is different now. Things old people once said to me are now coming out of MY mouth. Things like "I choose which battles to fight these days" and "they will learn in time" and "it is not my job to teach everyone."

When it comes to a client and delivery at work, I give my all. The long conversations seem worth it. When it is my peers and people I watch or interact with because of work and who aren't my clients then I seem to stand back now. It still irks me or even hurts my soul to not interject but something in me simply doesn't care enough anymore.

There is this amazing thing called the Internet. Stuff is moving fast. What you understand as the "best practice" or the "standard" may have been that once but it isn't now. I spend so much time looking at better ways to do things and new reasons for doing it that way. That is not an assumption I can make for others.

Keeping up with progressing technology and ideas is a job on top of your full time job but for those of us in technology, it should be a given. You can't just work 40 hours and go home and base everything on what little you did or learnt in that time. If you want to do that, study ancient history or paleobotany. The world of technology is not the place for you.

Hey, you kids! Get off my lawn!

Geek Girls Coffee and Microsoft Webinar

On Tuesday the 12th of February, I participated in a webinar (an online seminar) that was a collaboration between Girl Geek Coffees Sydney and Microsoft.

Pip Marlow

It was run in a panel format and the panel members were all from Microsoft:

• Pip Marlow - Managing Director of Microsoft Australia;
• Me;
• Andrew Le Lievre - Human Relations;
• Michelle Tea - Head of Services in Microsoft Australia; and
• Susanne Krohn - Early Career Employee and recent graduate.

The audience was a good mix of women in technology who are currently studying, recent graduates and those working in ICT at the moment.

Michelle Tea

The aim was to address audience questions around:

• What is it like to be a woman working in ICT?
• Was it a straight road to get to where you are?
• How have you dealt with negative experiences due to being a woman?
• What is important when companies like Microsoft are hiring people?
• (and the very important) What do you always carry in your handbag, other than a mobile phone?

Damana Madden (me)

There were great stories and a lot of good insight from all the panel members. The audience was able to ask whatever was on their mind and comment on different questions. It was a wonderful chat all round.

Susanne Krohn

These kinds of events are an awesome chance to get to talk to people who are working in the thick of it, in large companies like Microsoft with women participating in all roles.

Andrew Le Lievre

Kudos to Katrina Wong for organising this, along with GGC Sydney.

This is Not a Democracy

When I see people who I consider good leaders, be they of any age, gender, height or ethnicity, I see one thing that they do very well. They make decisions quickly. Quickly does not mean recklessly. It just means that they make a decision knowing that if it isn't right then they can correct at a later time.

Too often, I see people who decide for whatever political, career or other reason that they want to be a leader without understanding the fundamental decision maker trait. They go in to every situation and in particular meetings, as if they are chairing a committee that must come to a full consensus before a decision is made.

This is one of the worst things you can do.

Of course, it is right to listen to the group and take input and feedback at all times. That is a given.

The big mistake is to ask permission to move forward at every stage in a journey. This slows things down because of two important factors: 1) You can't always get everyone to agree; and 2) People don't always want to have to make the decision for you.

The latter is important. That is one reason why people like leaders. The responsibility to deal with consequences often falls to them. Others will assist but they don't want to have to be the ones who decided that things be done. This in itself is not a bad way to be. Not everyone wants to be in control of every situation. That is why we sometimes lead and we sometimes follow.

Making every decision by committee can also mean that the "wannabe" leader loses trust because they look indecisive.

If you want to lead then just lead. People will forgive you errors if you can fix them. If you share the same goals and want the same outcomes then there is nothing bad about deciding now and apologising later.

Not every group has to function as a democracy in order to work.