A view of the modern Business Analyst

Our organisation has a very diverse group of people responsible for the development and maintenance of our in-house IT systems. There are over 50 developers, working on hundreds of products, over 3 cities. Stakeholders include product owners, managers and users from relatively diverse business units. On the technical side we have BA’s, developers, architects, testers, delivery managers and more. Given all this diversity, one thing has stood out for me: having a good BA can make or break your effort.

This then leads us to the question: What is a good BA? It’s a very difficult thing to quantify, because quite often, we don’t really understand what we expect from our BA.

Our organisation used to expect them to thoroughly and meticulously detail the requirements for any new development. For months they would sit down with customers, and draw up pages and pages of lists of things the software should and shouldn’t do. Really keen BA’s also included diagrams depicting data and process flows. They would do all kinds of modelling to exactly indicate every eventuality. The reams of documents would then be signed off, and sent to the development teams. The BA’s would then move on to analyse another part of the business by creating a new set of requirements for another piece of software.

As far as the software products go, it didn’t work very well. The developers were invariable left with such vast and daunting tasks, that they just seem to ignore all the specs, and wrote a piece of software that they thought would work for the users. Sometimes they sought some input from the users. On rare occasions they even got it, and those were the more likely projects to succeed in providing some semblance of success. One of my colleagues remarked that in the 3 years here, he has never worked on a project that went live.

Our partial solution to the problem is agile development. This seems to be working very well for many software development groups (think Microsoft, Google and others). Without going into a discussion of agile (there’s plenty of them around), following it left an interesting dilemma. What to do with our BA’s? You see, traditionally, we expected them to fit in between the users and developers. Other, more advanced organisations, expected them to stand between anyone of a technical inclination and the users. In university, we were taught that the expectation of the business analyst was to represent the combined knowledge of the business unit in documentation so it may be encapsulate in software systems.

With the agile approach, we chucked a lot of that out the window. We invited the users to the party. We started interacting directly with the first tier owners and manufacturers of business knowledge. We changed our waterfall model which had everyone only partaking in a stage of the development. Under the new agile approach, everyone is a part of the entire lifespan of the project. The success and failure is a shared burden of the entire team, all the time. If the product get to UAT, and isn’t what the users wanted, everyone is to blame.
The good BA’s developed a new position in the process. They moved from being the guardians of the business knowledge to gentle facilitators. Instead of being a link in a game of Chinese Whispers, they set up telephone conferences. They stopped planning systems that would hide the processing difficulties, and started helping users to better understand their processes. They became less involved in the technology, and more involved with the problem. Together, we are changing the old pattern of creating expensive systems that perform inefficient tasks. We are making change where it’s cheapest, and most effective.

So where do we stand with our expectations from Business Analysts? What is the distilled essence of their function? In my opinion, the modern BA has one imperative: Empower the business to collaborate effectively in the creation of fit for purpose software.

When a BA strives to attain this goal, it makes life easier for me, as a developer. When I ask our user representatives whether they would mind if we cut the print function down to only print the component you’re looking at, they can actually debate the merits of either approach! In the old days, there would be no option, leaving you to implement the function as it was specified. You would have to create the page that allowed the user to print all 50 pages of tables and graphs, and would never be used because it took too long to load. Now, the specification is updated (by changing the acceptance criteria on the user story in the product backlog) and we can devote our effort to things that the users really care about, like improving navigation between the different tables and graphs. With empowered users, we can focus our resources to where it matters most for them. With BA’s focusing on the problem rather than the solution, many more possible solutions can be generated. Solutions can now involve changing the way users work, rather than the system they use. Our products are now going live, and the users are satisfied.

How to enable tracing on WCF services to troubleshoot things like serialization errors

This is an excerpt from an article on MSDN on tracing. Details can be found there.
It will help you debug that annoying "The connection has been forcibly closed" error, that has no usefull information attached to it at all.

1. Add the following code in your web.config or app.config for the WCF service:
<configuration>
<system.diagnostics>
<sources>
<source name="System.ServiceModel"
switchValue="All"
propagateActivity="true">
<listeners>
<add name="traceListener"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData= "c:\log\Traces.svclog" />
</listeners>
</source>
</sources>
</system.diagnostics>
</configuration>

This code should be added after the
<configSections>
element. Not doing so will cause an error.

Alternatively, use the configuration editor at Start -> All Programs -> Microsoft Windows SDK v6.0A -> Tools -> Service Configuration Editor to enable the diagnostics.

2. Make sure the "c:\log\" path is created and accessible to the appropriate accounts (I've just given the "everyone" account write access to it, but the .net worker process account would probably be enough)

3. Open the Traces.svclog file with the service traceviewer, which can be found here:

"C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\SvcTraceViewer.exe"

or go to Start -> All Programs -> Microsoft Windows SDK v6.0A -> Tools -> Service Trace Viewer

And that's it. The service viewer will show you any errors that was logged, and provides a very handy way to drill into the details.

"Microsoft JScript compilation error: Expected ';'" when parsing JSON in Javascript

This is a nasty one that I struggled with a bit.

I had some code parsing a JSON string returned from a callback.
var layer = eval(jsonLayer);

This worked fine, until I changed the object that was serialized to and from JSON from a collection inheriting from System.Collections.Generic.List to a base object, with the collection as a property.

I suddenly started getting an error stating "Microsoft JScript compilation error: Expected ';'"

Changing the code to:
var layer = eval("(" + jsonLayer + ")");
solved the problem. ( eval("var layer = " + json); will also work)

A discussion of the problem can be found here.

It turns out that while my object was a collection, the generated JSON looked something like this:
[{a: 'abc', b: 'def'},{a: 'ghi', b: 'jkl'}]
The parser clearly understood this as a collection object being initiated.

When I changed the underlying object, the JSON changed to something like this:
{a: 'abc', b: 'def', c: [{d: 'ghi'},{d: 'jkl'}]}
The string now started with a curly bracket '{', instead of a square bracket '['.

When evaluating this string using eval(), this quite literally means the start of a new block statement, with stuff inside evaluated as a set of instructions, and hence the error. Putting the parenthesis around the string changes it's meaning to denote the contents of an expression, and it is then treated as an object initialiser.
Without the parenthesis, the statement occurs as a lefthand statement, but with it, it is a right hand statement.

‘Sys’ is undefined - The trivial answer

I struggled a bit with this error this morning.
I read plenty of blog posts about updating the references in your web.config file, mostly related to using pre-3.5 versions of asp.Net. Just google it to find these posts.

This post has a potential solution for .Net 3.5: http://forums.asp.net/t/1355308.aspx

My actual problem, was because I used the call to sys,

Sys.WebForms.PageRequestManager.getInstance().add_endRequest(EndRequestHandler);

in the head of my page. To be more exact, I used it in a .js file, which I included in the head. The ScriptResource.axd, which contains the Sys object, doesn't load till after the head (or later on in the head), causing the error.

The solution? Just pop the piece of offending code into the body. The cleaner, nicer way of course, is to register it as a startup script in the serverside code, which I do with the following line:

Page.ClientScript.RegisterStartupScript(this.GetType(), "RegisterEndRequestHandler", "\nSys.WebForms.PageRequestManager.getInstance().add_endRequest(EndRequestHandler);", true);

And with that, my problem is solved!

How did I figure it out?

Some of the posts led me to the fact that the Sys object is defined in ScriptResource.axd. I then had a look at another page which uses AJAX, and noticed that it loads that file along with the other js files.

To see this, your debugger needs to bind to the browser (VS2008 does it automatically), which allows you to debug javascript (very handy!). More info can be found here: http://weblogs.asp.net/scottgu/archive/2007/07/19/vs-2008-javascript-debugging.aspx

I then had a look at the list of loaded scripts when I got the error, and the ScriptResource.axd was missing, along with all the other axd files. Letting flow continue and inspecting it after the page had loaded, revealed that those scripts had now been added to the page. This lead me to try running the code in the body, which worked perfectly.

Optimal seniority distribution in dev teams.

In the following article, http://www.lostechies.com/blogs/derickbailey/archive/2009/06/07/the-impact-of-staffing-practices-on-software-quality-and-productivity.aspx
the author propose that a senior heavy structure is desirable for an organisation.

When reading this article, I find the last line of the qoute "They found no relationship between a programmer's amount of experience and code quality or relationship" significant to the discussion, in setting the baseline of defining seniority. This should be kept in mind when reading the article. It is stated at the beginning "a person may be capable of working at a senior level in spite of a relatively short career. It is also likely that an individual in an organization may be considered senior level only by years in the industry or pay level, while that individual may not be able to work in a senior level capacity" For the purposes of discussion, a senior developer should be defined in terms of skill and competency, rather than years served. Organisations using the second definition, will likely have a huge salary bill for long-serving developers, but relatively low ouputs for those departments. Keeping those long-serving but still junior/mid developers on, is therefore an example of bad cost-benefit thinking.

I propose that having a mid level heavy distribution would be closer to ideal. This ratio better supports organisational sustainability, makes hiring easier, better supports knowledge transfer and provides a better balance between specialising and generalising.

Some mid level people can always be expected to move away from development to join management or other more business focussed roles. Such is the nature of creative people. Others will replace senior people as they move away. When that happens, they need to be replaced. Mid level developers are usually easier to replace than senior people, due to being in higher supply. It is preferable to rather replace a mid-level person than a senior person, due to the amount of organisational knowledge a replacement need to gain before being effective in their new role. When moving intermediates up, they already possess a high level of this knowledge. When consequently a new intermediate is introduced, the knowledge gain required to restore the equilibrium is spread between the two moving staff members, thereby reducing risk. Having enough juniors to be able to move one of them up, extends this benefit chain, as junior developers are even easier to replace.

Hiring senior people can be a pain. They are expensive, scarce and difficult to replace if a mistake was made. Hiring junior people can be significantly easier. There are a good supply of them (they can be sourced from grad schools) and they can be trained to fit in the organisation, or easily gotten rid of if they prove to not be up to the job. Maintaining a large pool of mid level developers can serve to help avoid the headache of hiring senior developers, provided they are of good quality and have the potential to step up. This pool, however needs to be larger, as it may take a while for the members to gain enough technical experience and emotional maturity to be elevated. If the current pool of juniors haven't got anyone ready to replace a mid level, they can still be hired from outside to replenish the pool. When hiring mid level people, recruiters have a larger pool of candidates (promoting an internal junior or hiring an external mid). Having some available for promotion will negate the need to hire senior developers, and thereby the risk of them not having a proven record and organisational knowledge.

Seniority can be thought of as a function of a developer's ability to generate and share knowledge within his organisation. The seniority of developers depend on their position on the knowledge transfer scale. Senior people will generally be able to generate and transfer knowledge down. Mid level people will absorb knowledge and add value to it, but will pass relatively less of this knowledge on. Junior people can be expected to largely absorb knowledge. Passing knowledge on is expected to carry an overhead. The overhead to transfer knowledge to midlevel people is lower than for juniors. Once the initial knowledge is transferred to the midlevel people, they can then spread it between them, and to juniors. Having more midlevel people spreads the overhead out better when transferring to juniors (who take longer to get the point.) Mid level people also seem to be more willing and able to spread and share knowledge with their peers. It also serves as an oppurtunity to identify mid level people's ability to spread knowledge, and mark them for promotion.

When referring to Scott Bellware's article on specialization vs.
generalization, http://blog.scottbellware.com/2009/03/productivity-not-bailouts.html, we can further infer that having a well-rounded balance would be the optimal position. Mid level personnel would tend to be the more general workers, while junior and senior developers tend to specialise more. Have you tried getting a senior dev to test UI interfaces lately, or a junior designing those interfaces? Mid level personnel tend to be more flexible with these kind of tasks. They may not be as productive as seniors, but certainly more willing to do the grunt work, which they can still do more effectively than juniors.

Maintaining a mid heavy development staff will therefore make it easier to "roll your own" seniors, whilst taking advantage of the relative ease of hiring juniors from outside. It better facilitates spreading knowledge, as it takes some of the pressure of seniors, while mid levels can teach each other and juniors after acquiring knowledge initially from seniors. Lastly, it gives a more versatile workforce, that prevents having a bunch of bored seniors unwilling (and financially ineffective) to clean the plumbing and can still herd juniors through uncertainty.

My first post!

For a while now, I've been nurturing the idea of starting my own blog.
Several people have influenced this decision.

Mostly, it has boiled down to outdoing some friends (you know who you are). I'll probably add them as writers for the blog, as we've been discussing setting up a blog for us to document the stuff we keep on looking for on the InterWebz (and surprisingly often seem to have to figure out ourselves.)
There has also been Joel, and his expectations of people he'd like to hire.

So now we've got the motivation covered, let's discuss the content.
This blog will mainly deal with software development. I'll probably post some solutions to problems I've encountered, small tidbits of interesting stuff I uncover, and some ideas regarding the software development process. Technical dev postings will mostly deal with C#, SQL and other Microsoft technologies.

So by now, you might have wondered about my background. I purposely keep this for last, when most people would already have clicked away, and only the very commited (or insanely completionist) is still reading this post.
I grew up in a small town, where I had some friends with a computer store. Hanging around this store fed my love for computers, and the stuff that makes them tick. After school I went on to university to do a B.sc IT, majoring in computer science and psychology (don't ask). During this time, I drank lots and had wild parties. It subsequently took a wee bit longer too finish the degree. I also held part-time positions as a sales person and later technician in a computer retail store. Geek heaven. There was a brief stint in a roadside assistance call centre, which taught me lots about dealing with Angry People. At the end of my degree, I joined a small software house, and started my career as a software developer. Which I still am, two employers later.

And so starts the chronicles of my attempts to liberate the software industry. A quest to improve the quality of our products, and a desire to share enlightenment with my fellow Code Monkeys.