All things Software

IT Project Planning

2011-09-08T18:56:00.000-07:00

Project Planning Online

Project Planning Online: Ever wondered why so many IT projects fail to deliver? Is it down to a lack of project planning, such as not fully understanding the requirements?Is it that requirements or scope are not fully defined and keep subtly changing, making it very difficult to track them?Is it that large areas of scope are not identified until part way into project execution, and then discovered to be key to delivery of the whole project? Regardless of whether this is considered a change, not delivering is always a failure, no matture whose fault it is.How can we make things easier? Project Planning Online would certainly help here - integration between the various operational and project based software allow for automation, alerting, quicker and easier changes that are make visible to all teams and stakeholders.Find out more at Project Planning Online.

Building a Website - Keyword Selection.

2011-08-04T22:42:00.000-07:00

Did you know that some of your SEO ranking will occur naturally, if you plan, and set up you website correctly? Once you have everything planned out, executing your SEO strategy, is going to be very easy.
If you pick niche, specialised keywords, you will pick up free traffic very (more...)

How to build a business web site - Keyword Selection - Keyword Research

2011-08-04T16:15:00.000-07:00

Search Engine Optimisation and the Search Terms that you choose

It is a good idea to put together a business case for your site, to focus your effort on the goals of the site.You may change your mind, from what you originally intended the site to be after reading this article. Don't become too attached to those initial ideas just yet, you need to validate them, and change them if your research shows that you site will be better off if you refocus, due to your new found knowledge of your customers, competition and offering.

Search Term Selection

Hey! Are you listening?Concentrate, don't miss this information.To make it worth your time putting together a website, you need to make sure that it is making use of keywords that search users search for.When nobody is interested in the keywords you are using to drive traffic to your offer, you whole effort is a waste of time.

Advertising can drive traffic to your site, but at what effort and cost?Are there other opportunities, other keywords out there that are more easily attainable for you?

Research your websites' focus

First of all, you have a niche, right?You need a focus for your site; otherwise it will not make any sense.What you're trying to achieve is to send people to your site as THE place to go for information on your niche.Is there some aspect of your niche that customers are particularly interested in and how would you know?There are a number of ways that you can find what people really want - listen to people when they talk, look in the paper, look in internet forums and chat rooms that are associated with your niche.Is there something that people are looking for?Do people discuss your niche?Is there a subject that regularly crops up that would describe your niche?

Understanding your Competition - How do they rank, and why?

A good way to start to understand your competition is to open up your favourite search engine, let's use Google, most people do, and type in a search that you would expect would find your site when you build it.The number underneath the search box once you have performed the search shows the number of pages that were found.

Open up some of the search results - who are the competition, do they offer the same product or service that you are intending to offer? Is their location a factor in their domination? Could you offer a localised version of what they do? If your customers have been around for a long time, offer the same products and services, in the same location as you, you're going to have your work cut out for you, to beat them.

If you really wanted to get into the nitty gritty, you need to know for each of those sites, their age, the number of inbound and outbound links, page rank, body content - all these things are big factors in the ranking of that site.

Search Phrase Analysis Sites

Some utilities on the net will help you to discover the search volume per month, and levels on competitiveness for your search phrase.Varying levels of related search term suggestions can be generated that will help you find the term with the best combination of search volume and low competition.

Tools can be found from the following:

Google Adwords Keyword Tool - free

keyworddiscovery.com

Wordtracker

Siphon the free traffic - Pick the correct keywords

If nobody searches for the search term that you are focussing on, it makes it much more difficult to generate money.Without a clear set of keywords, your SEO results are very likely to be random. You may get traffic, but it will not be targeted, or the results will be less than could be expected from an alternative keyword.Don't worry, something can be done about it, but it entails refocussing the site toward the correct terms.

If your keywords are chosen correctly, your site is more likely to be structure in such a way that it makes sense in that context, through the choice of headings, categories, tags, page content, backlinks, anchor text, image names, and the search engine is more likely to be able to find your content and rank you well for it, as you deserve.As you can probably see from the list of items that feature in making the site rank well, changing from the wrong keywords to the right ones is likely to require a lot of rework.

Can you choose keywords yourself, or should you pay someone to do it?

Due to the importance of getting the right keywords for you site, it is a good idea to spend a great deal of time researching the best terms, researching your competitors, niches and so on, before jumping in to creating a web site.
There is nothing wrong with doing this yourself, although paying someone to do this is highly likely to yield sales way in excess of the initial outlay, and continue to do so for some time to come.

Article source: How to build a business web site - Keyword Selection - Keyword Research

How to start a website in the right way with the correct Search Terms - Keyword Research

2011-08-04T15:27:00.000-07:00

SEO Keyword Research

It is a good idea to put together a business case for your site, to focus your effort on the goals of the site. As you read through this article you may have cause to realign your goals to make it easier to achieve success. This is good news actually, as it means that you have used completely understood your websites' purpose, and have eliminated that which is inefficient, given your new found understanding of your customers, your competition and what you are wanting to offer.

Search Term Selection

Hey! Are you listening? Concentrate, don't miss this information. To make it worth your time putting together a website, you need to make sure that it is making use of keywords that search users search for. You could be position number one in Google for keywords that nobody searches for, in which case the whole effort was totally pointless.

Advertising your products is going to cost money, are there easier ways to drive traffic that has a lower cost? Are there other opportunities, other keywords out there that are more easily attainable for you?

Research your websites' focus

Have you a niche? You need a focus for your site; otherwise it will not make any sense. When your visitors think about your niche, you want them to first think of your website.Is there some aspect of your niche that customers are particularly interested in and how would you know? Keep an eye on internet resources such as forums, chat rooms and blog comments associated with your niche subject, listen to people, ask your friends, look in niche publications. Is there something that people are looking for? Is you niche something that people talk about? Is there a core phrase that you could use that would describe your niche?

Understanding your Competition - How do they rank, and why?

A good way to start to understand your competition is to open up your favourite search engine, let's use Google, most people do, and type in a search that you would expect would find your site when you build it. When the results are displayed in the search engine, a number at the top of the results indicates the total number of matches found.

Open up some of the search results - who are the competition, do they offer the same product or service that you are intending to offer? Is their location a factor in their domination? Could you offer a localised version of what they do? If your customers have been around for a long time, offer the same products and services, in the same location as you, you're going to have your work cut out for you, to beat them.

If you really wanted to get into the nitty gritty, you need to know for each of those sites, their age, the number of inbound and outbound links, page rank, body content - all these things are big factors in the ranking of that site.

Search Phrase Discovery Programs

There are a few tools that allow you to understand the number of monthly searches that are performed for your core phrase, and how competitive it is. The good thing with these tools is that they are also able to suggest other keywords that may be applicable to your core phrase.

Tools can be found from the following:

Adwords External Tools: Keyword Tool from Google, which is free

Keyword Research - keyworddiscovery.com

Wordtracker

Correct Keyword choice drives Search Engine Optimisation (SEO)

If nobody searches for the search term that you are focussing on, it makes it much more difficult to generate money. Without planning the search phrases that you target carefully, using scientific methods that quantify what is required to achieve your goals, your SEO efforts are likely to be wasted. You will get traffic, but will not achieve the true potential of the site. It isn't too late - we can change that starting now, but redefining what the keyword focus should be, and concentrating our efforts there.

Your website structure should be clear given that you know your target keywords, the right page titles, webpage addresses, headings, link anchor text, body content, image tags, metadata will easily be found by the search engines, and will allow you to rank better naturally than you would without planning. As you can probably see from the list of items that feature in making the site rank well, changing from the wrong keywords to the right ones is likely to require a lot of rework.

Can I choose keywords myself, or should I pay someone to help me?

Build the site last - understand fully that you are trying to achieve before you start, including your competitors, niches, and alternatives.

This is something that you can do. The only downside is that it can be time consuming if you have never done it before. The effect of getting the whole process of SEO will generate traffic and sales way in excess of the initial outlay, so it is more a matter of priority.

Article source: How to start a website in the right way with the correct Search Terms - Keyword Research

New Business? Creating a Website? Want to know about traffic and SEO?

2011-08-02T16:24:00.000-07:00

If you're interested in how to build a new website and need help with web design, and what needs to be done to get free traffic or wondered what seo is, then go to this site. There are lots of very useful articles for people starting out with a new website, and these guys do a great job, and really want to help you succeed.

Visit The Brisbane SEO Company for more information.

New technology - If you don't adopt are you untrendy?

2009-07-10T22:24:00.000-07:00

I could have called this "The anti-pattern of choosing new technology" but decided against it in the end.

That probably gives you readers and idea of what I'm talking about in this post.

There are a lot of questions that I read that go something along the lines of "If I choose technology x, how would I make it work with the following scenario...". Spot the obvious mistake there?

The architecture always comes first, then start simple, and work to the more complex, or unknown solution, as requirements discount the most simple ideas.

If more architects of systems thought like that, certainly a lot of the work I have done over the years would not have been necessary. Somebody believed that a particular technology did something in a particular way, pushed it a little harder, and found that they were too far down the implementation to pull back, as the technology no longer fitted the requirements at all.

A case in point, and the forums are flooded with questions surrounding it - is LINQ. Don't get me wrong, I have nothing against the technology at all, it is great, in the right place. Honestly though, unless you have a very good justification for using it, it's quite probable that the old data reader / data adapter and sprocs is going to be a simpler and more understandable solution.

My problem with the technology is that it uses some logic to try to get the best performance out of a query - it's good, but I'm afraid, it isn't as good as me. What I mean there is that you have little control over how a statement gets implemented, so how can you possibly tune it? That for LINQ to do, right? So long as it does, that is fine.

So if you're starting out designing applications, take a bit of advice, and keep it simple, understand the technology fully before using it in big commercial applications where it ends up needing o be worked around.

Separation of Concerns

2009-07-10T22:12:00.000-07:00

Here's the thing - recently I put together some questions to use for interviewing, and one of the questions on there was simply what was "separation of concerns".

None of my team got that question right, although some of them are quite experienced, but all of them told me that this was a dated question that will only invite a textbook answer.

The point here is that a good design has good separation of concerns, and is coherent, but what does that mean? Simply put, a subsystem with a particular responsibility performs only that set of tasks, and no tasks for other subsystems. It's a little like the normalisation rules for databases, that the key must refer to all the data in a table.

This poses a couple of immediate questions, what happens when you have a Person subsystem, and want to get the addresses that that person resides at, without making a chatty set of calls?

There are a few approaches - if we're talking services, then the service call is very granular, and uses a DTO in effect to transport data from multiple sources. In the backend, the multiple source are nicely separate.

If the problem is considered from the backend, the Address subsystem would have to be injected into the Person subsystem, and vice versa. In this way you are delegating responsibility to the correct subsystem, however, this could lead to many calls to the database. Do we care? Well, we might do if the data really does have to be realtime, which is wouldn't in the given example above.

The final implementation would be to implement functionality (a PersonAddress nested subsystem within Person subsystem) or an AddressPerson nested within the Address subsystem. These would have a very different focus, or context, but the code is quite likely to be repeated in both. I guess that final point is similar again to the database example, in that generally you should start with 5th normal form, then work backwards to compromise redundancy against speed. Same with coherence, but it is "separation of concerns" versus maintainability.

Decoupled design

2009-07-10T21:49:00.000-07:00

Okay, so the question got asked on the Microsoft Forums about what was most appropriate, an interface, or an abstract class, so I thought that I'd bring that discussion over here for further discussion.

My response was to decouple, you would definitely use an Interface.

I was responded to with the question, but doesn't Inversion of Control containers now take care of abstraction, of de-coupling. I have to agree that it quite probably does.

That got me thinking, if you did use inversion of control, and always used abstract classes with no implementation, you would effectively have an interface. So why not use abstract classes everywhere? For me, it all comes down to clarity - the naming of an interface means that it is easy to understand it's function. An abstract class, on the other hand could be something ranging from effectively the interfacing class as described above, to something with lots of references to other abstract classes.

This is where I stand firm - my definition would be correct, if only to prevent that very thing from happening. When the implementation is part of a big team, those sorts of things can easily creep in, and before you know it, that beautiful, loosely coupled architecture is now reduced to a monolith.

So my advice here is always use interfaces, if you need an abstract class, create one, but only ever reference it using the interface. This bit here is another place where it is nice to have an interface - what if the base implementation changes? You can still create another base implementation class, and so long as the contract is unchanging, only that need change.

Coupling of code is all about the coupling of implementation from one to another - the very thing you have to avoid with SOA implementations and the like. The service call must be completely encapsulated.

Unit Testing in VS

2009-02-22T03:30:00.000-08:00

Can't believe it, every time I look at it, how comical it is - generate unit tests from code.

Yeah, it allows you to get tests up and running quickly, but makes one big supposition - that the code that you're generating a test for actually works.

Make TDD easier, and remove the feature, it's silly.

Martin.

LINQ

2009-02-22T02:55:00.000-08:00

Hey guys!

I have to say, I'm a little disappointed.

Having played about with LINQ briefly I thought it was a really good idea, especially having to not need to work out complex joins and the like. I thought that is was a really good idea.

If you push the technology to the point where you threaten to use it in an enterprise solution, I found that whilst you don't have to work out the SQL side of things, or the joins, really you do. Some unexpected side effects within LINQ, such as not being able to mix and match LINQ to SQL and LINQ to Objects, so running in to problms with code re-use means that the technology requires a much more in depth knowledge than one might be required to learn to use stored procedures.

I also found that performance in the simple scenario was great, but again, if pushed hard the technology was not great performance wise. That meant that using LINQ meant mixing and matching the LINQ language with stored procedures, which in my mind at least undoes it's purpose - language independence.

One other thing - if you want to keep a traditional data layer, without any technology bleed, and make LINQ work properly, well basically, you can't. It seems that each layer having its own model, whilst a good idea in theory isn't something that you'd really want to do with LINQ. I might be being unfair to technology, but from what I could see, the LINQ objects needed to be used to keep state information, which makes the technology basically a desktop technology, much like the dataset in a lot of ways, but with a fancy language to sit in front of it.

I'm going to keep going with the technology, as I like the concept, to see if I can find a way around it, to make use of it in such a way that it is actually useful, but at this point, it simply seems like a fancy language, with some very cool technology, but no real follow through. Really, that's a shame.

Static classes and methods?

2009-02-03T23:54:00.000-08:00

Hi,

Here's something that I really feel most people miss - questioning why they do something design wise.
A lot of people use static classes for reasons of laziness, it's easier to declare something as static than to create an instance and call methods on that.

Here's the thing, static classes generally go against OO design, you can't put an interface to a static class. That means that the code is going to be coupled to implementation, and so is not as easily maintainable.

I love unit testing, ideally with mocking, so my natural inclination is toward dependency injection. The resulting code due to following this approach with TDD is naturally a lot cleaner.

All static classes should be a thin veneer on an instance class, and so are then implementing a singleton pattern. I can see no other need for a static class - there's always an easy way around any other argument I have come across.

Take for example that it's nice to have access to a static class such as, MyDataLayer.Save(data). Instead how about defining a private property within the class, and lazy instantiating the reference within the property get? So for example:

private IDataLayer DataLayer
{
get
{
if (_dataLayer == null)
{
_dataLayer = new MyDataLayer();
}
return _dataLayer;
}
}

The only excuse you could have here for not using this approach is being lazy. This also allows you to inject dependencies through a special constructor, and the code will still work, so you can still unit test, and still get the easiness of static classes without all the drawbacks!

Happy Coding!

Martin.

Real world architecture

2009-01-31T18:36:00.000-08:00

Okay, so here's the thing - are there situations in architecture that really push you hard, drive you to come up with something of a compromise to achieve something placed upon you outside of your control?
I know that this particularly situation comes up, it's a bit like the 'on the buzzer' round on a game show. You have to think up something really creative to get around the constraint. yes, I know, the company doesn't have mature software development processes, blah blah blah, but sometimes these things happen that push you that bit harder. Come up with a solution that doesn't feel like it's selling your sole to the devil whilst still achieving whatever underlying constraint. I've been there many times, some companies have a better setup so this situation does not arise, but most do not in my experience.
So what do you do when this happens? Is there a core approach to architecture in this situation? I believe that there is, that we can have an initial approach of core process that we can use.
My first point is based around agile projects, all software development is an agile project to one form or another - I've never seen a project where the customer is happy with the outcome and doesn't want to add to it. That's not agile, but it should be! Anyway, I digress - what if you could put the architecture together an not case about such change? What I'm saying there is expect it? Changes the mindset somewhat, it is invigorating to not be constrained by the shackles of inflexibility is it not?

There's a couple of patterns that can help - first and foremost, the factory - delay implementation detail to a later date. This is a great start - its nice to be able to not care too much about the 'how' something should be done, only the 'what'. Okay, so most people are saying 'Duh, that's obvious'. Yeah, it probably is obvious by itself.
So I'd like to introduce the strategy pattern - this is a nice way to again abstract the implementation about from the function. Again, not exactly cutting edge thinking, I know.
Join those two concepts together, and we get something that Microsoft call the 'Provider' pattern. That is music to my ears - we now have a plug-able solution where were care a lot less about implementation. Sure we need to know the intent, but if someone changes their mind, which they likely will, we are happy to accommodate (in the next phase of course)
The second important thing to have in place is unit tests. I talk about them all the time personally. It's like driving without a seat belt, sure, you probably won't have a really bad crash and cause massive injury, but there's nothing like knowing you're creating a safe environment.
The only other constraint is to use proper OO techniques for encapsulation. So for example, you never expose anything like an IList, instead you would expose IPersonList, so you can change its meaning without affecting the solution. Let's face it half of that List<> functionality is going to go unused anyway, so why complicate matters and expose the whole interface? Yes, it's going overboard, but it insulates the project largely from change, and once you get used to doing things this way, it's not a big deal. Just seems pointless until the penny drops...

So, that said, what if you want the architecture to be SOA? Don't care. Why not have both, or some intelligent solution?

I'm thinking that there are people out there who have similar ideas an experiences? Please leave a comment if you do!

The best software to do "x"....

2009-01-31T18:11:00.000-08:00

Hi,

Been pulling my team together for a new project, and whilst doing so, have been looking out for software that allows us to do things properly.
Now, before I start, I have to admit, that I absolutely love TFS, and VSTS, and that really makes it difficult to look for something else out there. Being realistic, to keep costs down in the current economic climate, I have been on the look out for cheaper or free alternatives. It seems that they're few and far between these days.

So first of all - non-VSTS unit testing? Well, clearly we're going to want a mocking framework there - that one is easy - Rhino Mocks. I've used NMock, which was great, but I find that once you're used to it, Rhino is the way to go. I tried Moq but found that it was less powerful than Rhino.

Okay, second on the list - code coverage. This one is difficult, Microsoft used to have a product, Coverage Eye which I used on a few occasions, and worked really well. There's NCover - that's quite expensive now, it seems, almost to the point where I should be considering VSTS which seems a lot better. The only alternative I found was partcover - it works, but the experience isn't at all integrated. And that leads me on to another point...

Unit testing framework... Okay, so the integrated MSTest framework is pretty good, and I get why you'd move the test output to a completely different location to where you would normally run from - to run the tests in isolation. No complaints from me there. However, trying to hook code coverage in to that build location from a coverage component that wasn't IDE integrated, and thus could easily capture the test folder location, is a pain. So much so that I'd suggest that using NUnit is unfortunately a necessity. The trouble is that then we're working development from our IDE, and tests from NUnit, which fires up code coverage. Not too bad a solution, but it can be a pain.

Personally, I'd really like to see something more in the professional versions of VS, what I'm saying is that every organisation is not so big it can afford, or wants to afford the all singing all dancing solution, much as I'm sure most would if it was cheaper. I'd love to see either the integration through VS to be brought a little more to the surface to open up the free version use a little better.

As previously mentioned, I love what Microsoft has done with Team System, and TFS, really I do, and I think for corporations that are able to afford it, they will go with that model. I would given the money, no doubts. Though, the alternative at the moment is really not the most compelling - I know, you say, "Save up and buy the proper version then", but at the moment, simply that's not going to happen, which cheapens the experience.

I think that the opening up of the IDE should be a little like love, you don't know that you've got it until you set it free!

And Microsoft, keep up the good work with these tools - for the first time in a long time, they really are impressive!

"Signature of the body and declaration in a method implementation do not match"

2008-04-03T15:27:00.000-07:00

Whilst teaching somebody about unit testing and particular mocking, I came across an error with some code that said, "Signature of the body and declaration in a method implementation do not match".

This seemed like quite a bizarre error message, and worried me, since there wasn't anything immediately obvious as being a problem.

After looking into the problem for a while, there was no help on the net for it, and a whole lot of 'binary search commenting', I tracked the problem down to being a class that had a generic method.

The lights came on! The problem it seems is that whilst in the code it wasn't changing, it was entirely possible for subsequent calls to the generic method to pass different types to that method, thus affecting the method signature.

There's a simple solution, it is to make the whole class have the generic type on it instead, so for the lifetime of the class instance, it can only ever serve up objects on one type only.

Here's a small snippet of code:

What we had first:

public class GenericFactory
{
public objectType Create<objectType>(fullTypeName)
{
.
.
}
}

changes to:

public class GenericFactory<objectType>
{
public objectType Create(fullTypeName)
{
.
.
}
}

Nice and easy, since it is a bizarre error, I hope it helps some people out there. Beware of generics, unless you really understand what you're doing with them!

Martin Platt.

BUG - VS Code Coverage automatically closes testrunconfig Dialog

2008-03-11T18:02:00.000-07:00

This refers to a solution which has a project that is a custom project template, such as BizTalk or Reporting Services.

When the testrunconfig Dialog box is opened, either by double clicking it in solutionitems, or through the test menu, 'Edit Test Run Configurations', when the Code Coverage item is selected, the dialog box disappears.

The workaround is to unload the offending projects allows that Code Coverage item to be changed, but be aware that you might need to reload the project to allow the tests to run after making the code coverage changes.

I have this logged as a bug with Microsoft, but as yet is not officially confirmed.

Unit Testing - Watch out!

2008-02-18T18:25:00.000-08:00

I just thought that I'd write a little article to discuss some of the things to watch out for when unit testing. People tend to talk more about why it is or isn't good, and that you should use it, I'm proposing to tell you what to do when you do!

The first thing, the level of confidence in the test of the application is only as good as the tests that you write. Seems obvious, right? Using unit testing techniques does not make your code any more manageable, or correct if the tests that you write are of a poor quality. so all that you can say about unit tests, is that the code passes for the tests, and never that it 100% works, unless of course you are 100% certain that you have catered for all eventualities in the code.

Using code coverage as a tool to target your tests will not guarantee anything about the quality of confidence you should have in those unit tests. Here, I mean that having 100% coverage means that all the code is tested; it doesn't. What it means is that all the code has been exercise, but not that the code has been exercised with every possible value. We tend to use boundary conditions and the like to use in our tests reasoning that these values will best test our code. They don't, they're only representations.
Code coverage, you might not be able to exercise 100% of the code, if your code uses some .NET object that you can't exercise all the CLI for. You should find out whether that is the case though. It can often be an indication that the boundary condition by itself is woefully inadequate.

Integration tests. Until you do integration tests, you can't only speculate as to how well the code will work in the real environment. What happens if you get data that you didn't expect? What it means is that you write more tests, so that it doesn't happen again, even if the data was in error. The further upstream you go in terms of integration tests, toward a full system test, the better the tests are, and the more likely it is to fail. You're using real data, in real situations, and so can have a certain amount of confidence that the components at least work in that real world scenario. Look at exercising as much of the code using the coverage tools again, obviously some parts, such as testing exception handling belong only in the unit tests, but anything that can have data driven through it, to get as much coverage as possible is good.

If we do things right, then when we find errors, we write more tests, so that the tests become more and more complete, and our experience in where the tests could fail with the components increases, and thus gives us a better indication and knowledge of the risks involved with deploying the software.

So long as we bear in mind that we're never going to be able to say with 100% certainty, that a component is 100% bug free, we're probably safe. What we do with unit testing techniques is mitigate the risk, improve our knowledge of the system and its inner workings thus limiting risk and document part of the system.

These techniques are very useful, if used to their full potential, but never make a sweeping statement that the software is 100% bug free because all the tests pass, since that proves nothing.

Happy coding!

Software patterns - useful or over-used?

2008-02-12T20:12:00.000-08:00

Recently, on the MSDN forums I had someone comment that design patterns are largely over-used. The answer I gave to a question involved the use of a design pattern for a developer who was clearly inexperienced.

The comment was that the developer should learn proper OO techniques rather than simply saying that they "would use that pattern". I would tend to agree that understanding proper OO principles is a pre-requisite to most jobs in the software industry these days. That got me thinking, does using design patterns give rise to a set of developers who understand that they need to use a pattern rather than understanding the intent behind it?

I would say no. If said developer is using a pattern because someone said so rather than because they know that it fits their requirements, perhaps they need some career counselling.

That brings me on to patterns. A pattern is a well define solution to a particular programming problem, and that solution may in fact consist of a number of patterns to make up the full solution.

It is very true that you could use TDD, and evolve such a design, or pattern, and that might be the acceptible way to approach the situation, it certainly would be if you're using pure TDD. It just seems that having an idea of possible approaches, a solution space, if you like is a great idea. It gives a set of scenarios to consider, or a set of implementations that you must consider, which is a good thing.

Then, if you're not doing pure TDD, you might want to adopt a pattern, which is a well understood way forward to implementation. If you're an experienced developer, you'll probably have implemented these patterns before without calling them patterns, so in that case, it's a descriptive label to put on an "experience catalogue". It means other developers who have also developed using those same algorithms can have a common understanding of what you're talking about.

Primarily, I see this as the major force behind patterns. The ability to communicate a shared understanding of a design, in a short and succinct manner.

People have often asked me what they need to do to make the code a such and such pattern, or instead, which falvour of the pattern is this, I want to use this pattern, how can I covert it from a similar pattern to that pattern? These sorts of questions seem strange to me. The pattern is there to help you think about the problem in isolation, decoupling, and good things like that. Whether it has one name or another name is really irrelevant, it's all about whether the software does what it is supposed to, and does it in an efficient manner.

I have also come across situations where people try to follow the pattern to the letter. To me, a pattern is a template, but there is no reason why that template can not be extended to fit the problem space, so long as that design is well considered.

So in commenting that software patterns are over-used, that really is kind of like saying that experience is over-used and overrated. Patterns, whilst they're not a new idea should be used more, if nothing else so that it is an enabler for communication.

Making a mockery of Testing

2008-02-11T14:17:00.000-08:00

How much testing is enough testing?

If for example, you have to deliver a piece of software, some functionality and you have tight deadlines to meet, is 50% of code tested sufficient enough? How do you know that you have tested the most likely to fail 50% of the codebase?

That question probably sounds quite silly, but whenever I mention to people that they should be using Mock objects to test, they say that it is overkill, and that unit tests are enough. Further probing often reveals that these unit tests are really integration tests, tests such as ask for a particular record, or match filter to return records, and if records are returned, the test correctly passes.
That sort of a test is as brittle, weak and unknown a code fragment as the code fragment that it actually tests.

The database goes does, is that a code failure? Bet there's no test for the server actually going down, and if there was, how would you be able to descriminate between an infrastructure problem, and a coding error?

There are two approaches, one is to write tests, using MSTest, NUnit or whatever else you like to use, you pass a value, and expect a given response. This situation makes it incredibly difficult to test all of the code, since you have no way to control flow through a particular code branch. An example would be testing the exception handling block of a routine, given a unit test, there is no way to inject the exception into the code, so you're stuck with compiler switches to throw exceptions. Compiler switches is changing the code from what it will be in production to something else, which carries its own set of risks.

The alternative is Mocking. Now the concept behind mocking is that you create objects that are effectively proxies to the interfaces that a particular method or class uses. You then set expectations on those objects, and tell them to return data, which effectively drives the code through the desired execution path.
In that instance, if the database goes down, the tests will still pass, you are just driving the interface that is implemented at the data layer. You can't be touched, nobody can take that code down.

As a shortcut, to achieve that deadline, how much time would it take up to consistently and continually test and retest the code with such rigour?
Another question you will be asking yourself, is, is 50% tested code enough now, and will it actually take me less time to resolve all the bugs in the code using the debugger continually, instead of having repeatable and isolateable test targets to check instead?

Keep an eye out for a further article on how to do some mocking to enable the test coverage statistics to get up into the 90% area with nearly all classes.

Real world test driven development (TDD) - Perhaps "Requirements Driven Design and Development"?

2007-12-29T16:35:00.000-08:00

Test driven development seems to divide programmers into three different camps; those that think that it is the best thing since sliced bread, those that think it is a good idea but impractical due to the time it takes to use, and those that are completely ignorant of what exactly it is.

It seems, that if you start to try using TDD for any projects, it will very quickly become clear why you might want to implement using this technique. Simply, it isn't so much about writing tests, but more about evolving a solid, loosely coupled solution that meets the needs of the requirements and nothing more. From the point of view of that statement, surely nobody would argue that up front design is a good idea, and in so agreeing to that statement, you also agree that you agree with the principles of TDD.

But there's more! As a by-product of evolving this wonderful software design, that is neither over-engineered nor highly coupled, we also end up with tests, and code!
It probably seems strange that I have mentioned that we end up with tests; very quickly a practitioner of TDD will notice that tests are manifestations of the requirements.

So we're really looking at test driven development from the point of view of what we want to do with the solution, which is the software's requirements. This technique doesn't in any way imply that we don't gather requirements, but what is does do is allow us a framework by which to evolve yet more requirements as they become apparent. What I mean by that is that we have a bunch of tests, that will always test for functionality, and should that functionality cease to work correctly, the test will fail, and the requirement will not be met. This means that we are then able to add, or change functionality, and know that a particular requirement is or is not met.

Well, I've worked on a few projects in my time, and in every one, we are asked how far from completion we are. How can we tell? Well, if we're sensible, we have some unit tests. The number of not yet implemented tests, and the number of failing tests should give us an idea of how far we are away from a successful build of the solution. We now have a technique that allows us to design our software according to requirement, and produces tests to give us an idea of how we are progressing.

Upon implementing the code to allow a particular test to pass, we also develop our code solution. Now, I'm wondering how we could possibly not want to develop good mature designs, unit tests and a solution using a technique that is directly aimed at that process?

One major barrier to the use of TDD are things like patterns. Don't misquote me here, design patterns are awesome, but what they often do is give a developer a design possibly before they fully understand the problem space. What that means is that as a developer, we're often tempted to jump straight in and start coding, without full consideration of the requirements. TDD forces you to implement only what is needed of the solution and nothing more. Design patterns lead developers to thinking that TDD is slow because they already know all the answers. What they should really be asking is, does that design pattern come with code and unit tests already constructed for their requirements. Almost certainly it does not.

Instead of rushing to start with a preconceived idea of implementation, a developer should instead use TDD to evolve the design. When it becomes apparent that the solution has evolved to a point at which the use of a design pattern is appropriate, to solve a requirement, then it should be used. In using this technique, a developer has documented evidence that such a pattern is a requirement of the solution, through the tests that are already in place.

Test driven development really requires the use of mock objects, which are strange to say the least, until you understand how they work, and then they become invaluable. When the design pattern requirement becomes apparent, a new set of tests should probably be constructed to test the pattern separately. In the original test project where the use of a pattern was discovered, mock objects should be used to 'pretend' that the pattern is being called.

We use mock objects so that a particular test class only tests one class directly, and everything else is mocked, and so has been assumed to be working unless the mocked code's unit tests fail.

A big part of TDD is that we end up with a very loosely coupled solution. This is largely due to the mock objects that I previously mentioned. Mock objects should really use interfaces to access code, and not concrete classes. Using a class mock would make the implementation be coupled to that class and so would be easily broken, or brittle in construction.

In working through code attempting to use interfaces, a developer will often come across resistance in one way or another. The problems may be due to the fact that the .NET framework does not offer an interface to a particular object directly. In that instance, what that is actually telling you is that you need to create your own wrapper class and interface. This is actually good news, if you stop and think about it, you are in effect abstracting functionality away from the implementation in the framework. This process would allow refactoring to take place in a much simpler way, and would also allow that implementation to be swapped out should the there be the need to do so. It is starting to sound like the beginnings of a Strategy, or Provider pattern now isn't it?! Shhh! Don't tell the naysayers!
One thing of note is that when the developer is trying to mock and test a particular aspect of the system, and it becomes hard work, that is often a good point at which to reconsider the implementation of those requirements. In the case of an object that doesn't have an interface, that leads us to wrapping up something that essentially provides functionality for us. Implementing tests on such a design should be once again very straight forward.

Generics are somewhat of an exception to the rule. They're great for giving type to classes, but unless you can perform all your tests on the functionality with only interfaces, you should consider refactoring the design, or hiding the generic interfaces behind non-generic interfaces. If this becomes too hard still, you may well find yourself wondering whether the generic class is really appropriate. This process is good, but don't do as many people do and blame TDD because you can't test the code; or at least don't keep the generic class that you can't test unless you're happy to have all aspects of the system that the generic class touches also be untested.

Red - green - refactor. What a shame that somebody came up with that as a mantra for TDD. Write the test, it fails, implement the code to make it pass. Seems pretty straight forward in concept, but as you can see from the discussion above, there is so much more to it.

It is strange that so many people like the idea of TDD, but so few have actually found a use for it. It is also a shame that there is so little information on the use of TDD and its practical implementations. I have seen many a simplistic example, and have given then myself in times, but when the technique is used commercially we want to be able to use it to its full potential, and solve every problem we come across with it, otherwise we simply will not use it.

If anybody has questions regarding TDD, please leave comments, and I will do my best to find answers, or offer possible solutions for you.

Agile - Should we all?

2007-11-15T17:20:00.000-08:00

In the world of software it seems that it should be expected, no, encouraged that people come up with new ideas to make software more useful. Computing systems are no longer simple or can be conceived of in one effort.

With that idea in mind, why doesn't every project run in an agile manner? Well, I think it's down to the fact that people want to be able to budget, and constrain their costs. That's also of high priority, and completely understandable as an approach.

What happens then? Well, it seems that projects often have the higher levels of management, and those in charge of the purse strings winning the standoff. What happens then, is that the project becomes one that has all requirements defined up front, so that they can be detailed, and costs attached to them.

What happens now? Well, unfortunately, the prject is now forced into a waterfall type, up front design project. What that means is that either the client can't change their mind, and so can't evolve their ideas, or the project has to do work for new features without a budget. Is that good? From the point of view of the project is probably is, but the end product is going to suffer as a consequence.

Can we run a project an constrain it to a budget, and a project end date? You could do, but you would probably have to put limits on a budget for each iteration, which will in turn put a limit on the features. That limitation is imposed by the budget, so there's little we can do to limit that situation. However, what we do by running the project in this way is to allow the project to evolve and improve. Now, that's a good thing isn't it?

Why is it then, that most projects are not agile projects?

Risk, Who needs it?

2007-11-05T16:29:00.001-08:00

Hello,

You're a software developer, you love to live by the seat of your pants, right? You can't function without loads of pressure, and the vast amounts of coffee that goes with it right? You'll probably want to stop reading this then!

So many projects and features for a piece of software get into a project plan without consideration to the risks involved. The client wants it, therefore it must go in. Is that a realistic proposition? Well, it might be, depending upon what the feature it is, and whether the inclusion of the feature overrides the risk involved in its implementation.

Something to consider, if late inclusion of a feature into an existing project is going to take that software back to a beta version, and the risk is unknown, would you do it? I wouldn't. You need to know the risks, and you need to be able to predict the worst case scenario, and describe what aspects of the software will be affected.

Given these assessments of impact and risk, you can attach a dollar cost to the cost of implementing the additional cost, versus the cost of not doing so, and always look at the worst case.

Imagine the number of features that started life as a throw away comment, and ended up being a major feature in a piece of software simply would not be there if decision makers knew the true cost of doing someting versus the cost of not doing something.

Business Head Blog Launched!

2007-11-05T16:28:00.001-08:00

Hi!

Please visit the freshly launched "business head" blog, when you can rad how to set up and run a business. See it at http://teamplatt-businesshead.blogspot.com

Martin.

Need help with architectures, or coding?

2007-11-05T16:27:00.001-08:00

Hi,

If you need help with requirements, architectures, development code and the like, leave me a comment in here, and I'll help you out.

Cheers,

Martin.

Architecting solutions based on all the requirements

2007-11-05T16:25:00.002-08:00

Gathering great requirements from business analysts is one thing, finding requirements in an existing legacy system is another. The former implies a possible new development, the latter implies an existing system.

So many questions are asked, in forums and the like regarding new developments, and using the anti-pattern of redeveloping with new technologies, patterns seems commonplace, and yet it also seems that very little weight is given to that existing system. You don't hear of many people immersing themselves in that system, finding out what the real problems are, and testing against those problems to provide a more useful solution.

It seems to me that more weight is given to using in-favour design patterns, and new technologies such as WWF, WCF and WPF over whether the re-development of the legacy system is even cost effective, or provides any benefit.

Our proof of concepts should be an end-to-end solution that cover all aspects of the system, including those difficult areas that we want to avoid, as well as the 'buzzword ridden' layers that prove nothing that you don't already know.

Consideration of complete, end to end solutions, including as much functionality as is conceivable is going to leverage that proof of concepts' worth, and provide a good benchmark for timescales and cost benefits, as well as giving insight into areas of high risk and potential problems.

I know this bit of text seems to point out the obvious, but from my observations, that point clearly is not being taken on board.

We need to focus on business value, and the ability to make software solutions perform in a way that enables our clients businesses to succeed, instead of producing systems with all the latest technology, designed is a really complex ways that does nothing really well, and most things quite badly.

You boss is your client, and you client judges you on how well you perform, not how many acronyms you can place on your Curriculum Vitae!

Test Driven Development

2007-11-05T16:25:00.001-08:00

Test-driven development (TDD) is a particularly useful technique to grow or evolve clean, refactored and readable code with a high degree of confidence. Test driven development is oftentimes confused with a code project that has unit tests, these approaches are very different, and so are the outcomes.

Why would I tell you this?
Well, since using TDD, I’m hugely impressed with the outcome, and the quality of code that can be produced. I talk to people about the technique and sometimes get people to give it a try, but often that attempt only gets as far as unit testing, or don’t perform the process properly and they see neither benefit or point to it at all. I hope to change that view for you.

Where do I start?
To start test driven development, you need tests to drive the development! Those tests are likely to have come from business requirements, so if you don’t have those, stop, and get them; otherwise you have no hope of completing this exercise at all.

The requirements are usually expressed in terms of what something has to do and so can be quite easily mapped to tests. Now at this stage, it is quite likely that the tests, or manifested requirements are expressed about the system as a whole. That’s okay, but we need to know what that means – it means initially we’re building an integration test, something that tests the system as a whole, the sum of its parts.

When using TDD, there is a common mantra, “Red, Green, Refactor”, which are a basic description of what has to happen following the writing of one test. All will become clear as you read this article.

Now, let us assume that we have a simple problem, which we want to convert numbers to words to be printed on a cheque, or money order. So for example if the amount were $599.53 then our output would be “FIVE HUNDRED AND NINETY NINE DOLLARS AND FIFTY THREE CENTS”, our constraint will limit the amount to one thousand dollars.

We can start with something simple to convert $10 to words.

To create our first test, we need to add a class library for our tests, and add references to the NUnit framework. I will not be going into how NUnit is used here, but will supply a link to some NUnit information pages.

Here is the first test:

using NUnit.Framework;

using System;

using WiseLittleBirdie.ChequeWriter;

namespace WiseLittleBirdie.ChequeWriter
{
[TestFixture]
public class ChequeTests
{
[Test]
public void CanConvertTenDollarsTest()
{
ChequeWriter chequeWriter = new ChequeWriter();

Double chequeAmount = 10.00;

string expectation = "TEN DOLLARS AND ZERO CENTS";

string result = chequeWriter.Convert(chequeAmount);

Assert.AreEqual(expectation, result, "The conversion of 10.00 dollars did not return the correct result.");
}
}
}

Notice that the test so far tests for the assumption that the chequeWriter can be created, and that we’re then testing for the output to be what we expect it to be? We will come back to that issue soon.

The code we’re now going to write, will allow the code to compile, but the test to fail due to an incorrect result.

using System;
using System.Collections.Generic;
using System.Text;

namespace WiseLittleBirdie.ChequeWriter
{
public class ChequeWriter
{
public string Convert(double amount)
{
return null;
}
}
}

Now, the code will compile, and run, and our test will fail, which checks that the test is indeed valid for at least one failure value. Due to the colour of the circle next to a failed test, this is referred to as “Red”.

Now we need to make the code pass the tests, so we implement the minimum to allow the situation to be true.

using System;
using System.Collections.Generic;
using System.Text;

namespace WiseLittleBirdie.ChequeWriter
{
public class ChequeWriter
{
public string Convert(double amount)
{
return "TEN DOLLARS AND ZERO CENTS";
}
}
}

Now we see the test will pass, referred to as “Green”. We’re happy now, aren’t we? Well, yeah, but that code really isn’t very useful yet, is it?

Now onto the final phase, refactor. We need to look at the test code, and see if we can make that neat, tidy and economical.

First of all, since we’re going to be continually changing code, there are some things we need to consider:

· Should we refer to objects using interfaces? Refactoring the interface and code isolates us slightly from the changes that we will make.
· Should we find a way to define how we create our objects, so that if we were to change our constructor, it won’t immediately mean global search and replace?

Do we need to implement either of these techniques yet? The answer to this question should probably be no. As yet, we have no requirement to do so, since there’s only one object and only one test. Arguably though, if you know that you’re going to have to do it, it may decrease the pain if the structure is implemented in the beginning.

So at the moment, we have no worthwhile refactoring to do.

Let’s expand the tests to a further case, a similar one to allow us to show some progress.

We will test now for $999.99 now, and compare the result to what we expect again.

[Test]
public void CanConvertNineHungredNinetyNineDollarsTest()
{
ChequeWriter chequeWriter = new ChequeWriter();

Double chequeAmount = 999.99;

string expectation = "NINE HUNDRED AND NINETY NINE DOLLARS
AND NINETY NINE CENTS";

string result = chequeWriter.Convert(chequeAmount);

Assert.AreEqual(expectation, result, "The conversion of 10.00 dollars did not return the correct result.");
}

Now, since we have already written a convert function for ten dollars, we would expect it now to fail. We compile the code, and run the test, and it does indeed fail, as expected.

We now need to make the test pass, again, doing the minimum we require to make that happen. We don’t want to implement anything more than we need to, so that we don’t end up with untested code, or code that simply isn’t required.

Here is the newly changed Convert Method.

public string Convert(double amount)
{
if (amount == 10)
{
return "TEN DOLLARS AND ZERO CENTS";
}
else
{
return "NINE HUNDRED AND NINETY NINE DOLLARS AND NINETY
NINE CENTS";
}
}

Now, can we refactor our code yet? Certainly! Our test classes have a lot of repetition, so let’s refactor. Here is the new test code.

using NUnit.Framework;

using System;

using WiseLittleBirdie.ChequeWriter;

namespace WiseLittleBirdie.ChequeWriter
{
[TestFixture]
public class ChequeTests
{
private void TestConversion(double amount, string expected)
{ ChequeWriter chequeWriter = new ChequeWriter();

Double chequeAmount = amount;

string expectation = expected;

string result = chequeWriter.Convert(chequeAmount);

Assert.AreEqual(expectation, result, "The conversion
did not return the correct result.");
}

[Test]
public void CanConvertTenDollarsTest()
{
TestConversion(10, "TEN DOLLARS AND ZERO CENTS");
}

[Test]
public void CanConvertNineHungredNinetyNineDollarsTest()
{
TestConversion(999.99, "NINE HUNDRED AND NINETY NINE
DOLLARS AND NINETY NINE CENTS");
}
}
}

It now looks a lot neater, and it much more readable. If we run the tests again, we can see that we still get a green light, which mean refactoring did not change the result of our code up until this point.
I left the refactoring of the CheckWriter object to include an Interface and creation in a factory still because that call only happens in one place. It’s also possible to put the creation of the ChequeWriter object into a Setup method for the test class, which would be equivalent to what you can see above. I decided to do it this way at this time because then it makes the code readable.

I know that you’re thinking that this is a pretty stupid program, and I’d have to agree, at this stage it is. One thing we can say about our development effort is that without debugging, we can tell whether a value of $10 or $999.99 can be converted readily to be printed on our cheque. We can be 100% sure that this is the case.

Now, we need to come up with a further case. We now want to convert $109.99 into words.

[Test]
public void CanConvertOneHundredAndNineDollarsTest()
{
TestConversion(109.99, "ONE HUNDRED AND NINE DOLLARS AND
NINETY NINE CENTS");
}

That was nice and easy, wasn’t it? So there is a real benefit already.

Now onto the red phase.
public string Convert(double amount)
{
if (amount == 10)
{
return "TEN DOLLARS AND ZERO CENTS";
}
else if (amount == 999.99)
{
return "NINE HUNDRED AND NINETY NINE DOLLARS AND NINETY
NINE CENTS";
}
else
{
return null;
}
}

It fails, as we’d expect it to.

And now green.

public string Convert(double amount)
{
if (amount == 10)
{
return "TEN DOLLARS AND ZERO CENTS";
}
else if (amount == 999.99)
{
return "NINE HUNDRED AND NINETY NINE DOLLARS AND NINETY
NINE CENTS";
}
else
{
return "ONE HUNDRED AND NINE DOLLARS AND NINETY NINE
CENTS";
}
}

And that passes.

Now refactoring. It seems that since all our tests have been the same so far, we have no cause to refactor any further.

If we now do test driven development in the same way with more numbers we should expect that our code will grow. We should expect that the more test cases that we have, the more the code will become useful for other cases without the need for extra code. The situation is possible largely because of the refactoring phase which is about writing more economical code. The will be a point at which all the cases will be more efficiently expressed using a method or two to calculate the words dynamically. I won’t go any further at this point so that we don’t lose focus on the technique, but suffice to say that we should be able to implement a useful piece of code if we continued.

After we’ve written code to ultimately pass each test, and refactored, our solution should converge on a result that implements all cases. If it doesn’t then we need more tests.

It is important when writing code using test driven development, that we do not miss out stages. Incorrectly writing a bunch of tests then making them pass will miss out on the important stages of testing the tests, and refactoring. If instead we wrote a test, then wrote more code than was necessary to pass the test, we would also end up with an implementation that bigger than required (code bloat). This increase in code size to implement more that can be tested by one of our tests could allow untested code to creep into our project. We don’t want that as that is uncertainty.

So far we have been developing our tests as a black box, such that we have no idea of the implementation of the class. If we were working on a more complex problem, we would then start to define a set of white box tests to logically test the workings of the dependent classes. It is important with these unit tests, to only test the class which you are focussed upon. Any dependencies should be able to be passed into the class constructor, so that it can be replaced with a mock object. Please be on the look out for new articles based on dependency injection and mock objects.

Earlier I mentioned about making an assumption about being able to create a CheckWriter object. In the unit tests above, we would and should test things such as whether we can create the object. Other things to look for are testing somewhere if we can create a factory object should we require one. Factory objects will also be discussed in a future article.

An example of something that might require white box testing could be a data layer that is called by our top level class, to save some aspect of the data that we are manipulating. This class would be written again using TDD, but the tests be at more of a logical level. This would involve the tests not being based on instance data, and the correct operation of other classes, but only on them doing what is expected under the many circumstances that are defined by the unit tests.

One very useful type of tool for test driven development, in fact for unit testing in general, is a code coverage tool. The idea here is to make sure that there are tests sufficient enough to exercise all code execution paths within the class. A reasonable aim would be to get 80% coverage at least, as it is quite a challenge to get that sort of coverage. Users of the tool should not be tempted to fake calls by making them raise dummy code just to make the coverage value go up. You must always make the tests force execution of a given path, thereby testing the real code, and hence reducing the uncertainty that would be otherwise present.

NUnit: http://www.nunit.org/
Coverage Eye.NET: http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=881a36c6-6f45-4485-a94e-060130687151

Certifications (MCTS, MCPD, MCSD, MCAD, and so on)

2007-11-05T16:24:00.001-08:00

Well, the question is, are certifications, such as MCSD, the new MCTS qualification, and the MCPD qualification worthwhile? Do they offer anything in the way of learning new things, and do the prove to the wider world that the qualified do indeed know more than the unqualified?

Personally I did an MCSD back in 2001, and at the time found the desktop and distributed parts to be a case of learning minute detail to be able to pass the exam. The exception, and useful parts were the "analysing requirements and defining solution architectures" exam, which was a real challenge, and meant to me that you really needed to know your stuff. Personally, I think it's a shame that that exam isn't still available.

Having passed the MCSD back in 2001 I gave myself 6 months off, after which I planned to start studying again. So, after a 6 month break that quickly turned into six years, I'm back again doing some certifications.

At first, whilst studying the MCTS exams, I found that most of it I already knew, just that the names had changed. However, I was gladly surprised to find that there was enough tested knowledge in there to make it worth my while studying for it.

I would recommend that the MCTS exams are aimed at your bog standard developer, so if like me, you've done that sort of thing for some time, you will probably not find it a huge challenge. That said, as mentioned earlier, I believe that there's enough coverage in there to allow you to learn new things, and improve your breadth of knowledge.

Will sitting these exams leads to more opportunities when looking for employment? Almost certainly, if it's between yourself and someone who doesn't have any certifications, I know which one I'd choose, all else being equal. That's the key, if you have the experience, this adds to it, if you do not, then I wouldn't expect it to really give you an all areas pass to a job. I do see more recently, employers asking for people with certifications as "highly regarded". Listed as mandatory though, are a whole bunch of other skills and experience that you must have, so that gives you some idea.

Then there are those people who get hold of answers to questions, and cheat the certifications, personally, I think that those people do denigrate the certifications, but as mentioned above, someone passing may get them through the door of the interview, but when asked questions, or asked to do something practically, those people are going to have a rather public fall.

One interesting thing that also happened. Whilst studying for the exam, the practice exam software crashed, it seemed, in the C# certification area, so I switched the language to VB.NET and started the exams again. What happened then was that I wasn't really all that aware that I had changed languages, as the knowledge required was more often than not, the same. I also tried that theory out with a C++.NET exam simulation from the CD, and found the same to be true again. That did impress me, and lead me to the question that really a lot of the exams are language agnostic, and the certification is more with the framework than with the language.

I hope this little article is of interest to you, and that you will leave me a couple of comments, as to what you think, and if you agree, or it helps to spur you on to doing the certifications.

Good luck!

New Architecture for legacy systems

2007-11-05T16:22:00.000-08:00

I don't know what it is, but so many architects that I meet in the various projects in which I work are so focussed on writing new solutions with new technology, that they often completely miss the problem in the first place.

I've seen enthusiastic architects often propose solutions that replace the easy part of the solution, and make it "better" (when often it isn't broken) and then not even attempt, or only partially attempt to address the real problem.

Our anti-pattern is to replace all this stuff we currently have with new stuff, and still have the same fundemental problems as before.

Why instead, can't we take much more of an agile, iteratative approach, and replace things little by little, and slowly move away from one solution to a more mature one, without once putting all our eggs in one basket with a particular "buzz" technology?

What this whole process often involves is moving from one bad decision, to a new bad one, or worse still starting implementing a solution with a new technology, that by the time it is finished, is an old technology, and we iterate with the same.

To my mind, architecture is more about an approach, a pattern, that is agnostic of the technology that may be used by it. If we work toward a solution that looks like a pattern but instead uses a particular technology that completely undoes that pattern by coupling everything through the technology, then it seems a completely useless and expensive exercise.

A big area that seems to suffer from this particular ailment, is SOA and the web service based solutions. Often, I hear that the reason for choosing a web service based solution is because of a need to make that solution available, particularly to other platforms. Later, I find out that the solution is intranet based, and could have been implemented a lot better without the need at least initially for web services at all. We then get hacks based on that concept to achieve various things, largely borne out of the need for "cool" technology. Things such as WSE are such an example. Whilst there is defintely a place for these technologies, that unemotional choice is often not correctly made, in favour of a curriculum vitae boosting entry instead.

There really is a good case for technology aware-but-agnostic architects out there, my experience is that they are few and far between. An architect should be exploring all possibilities, rather than a set that suit their purposes, or career.

Unit testing, Test Driven Development (TDD)

2007-11-05T16:20:00.001-08:00

It still amazes me that there are so many projects out and about that have lots of lines of code, interoperating, and communicating systems, and no unit tests.

I don't know how projects get out in time, or even slightly slipping without having any confidence as to how much of the solution actually works.

I would have expected all greenfield projects, and some new additions to software to be able to be built using TDD, and be able to be refactored, and for delivery of the project to be able to be done with confidence.

I know that it often scares people to be using MVC and MVP patterns and dependency injection, but I know that it would scare me more to be in charge of a project that didn't have any unit testing.

Another thing, of projects that I have worked on that have had unit tests, they're often not unit tests, and are instead system or integration tests. Who cares what they are, right? If you run an integration test, and the server goes does, does that mean that your code has failed to pass its requirements? Will it take you an age to figure out if the problem is environmental including lots of debugging, and so on? Quite possibly, as there's so much involved in the real system, so many dependencies. Ultimately you need those tests, but to be able to write solid code, unit tests are what you need.

What else intrigues me is that you hear so many people talking Agile, and yet so few actually show any evidence of being capable of doing it. It seems implausible to run an agile project without unit tests to constrain your planned and unplanned changes to code.

I heard often of people complaning that test driven development takes a lot of overhead, well yes it does, but in the long term, that will mean less time to finish the project, unless it is the most simple project you've ever seen, and even then, I think you could argue a good case for TDD.

I know there are people out there who use Agile and TDD type methodologies, please show yourselves, and make yourselves known to me, and to the world at large!

Generalised, Generic, Configurable frameworks. Worthwhile?

2007-11-05T16:19:00.001-08:00

My opinion is no! I don't think that frameworks should be so generalised, as to not be able to do anything particularly well.
Generally I think, these sorts of frameworks are overengineered. The reason?
Well, what is the point in designing some framework that can be applied to literally any situation, but requires so much configuration and tuning to make it work at all? That doesn't seem useful to me, it seems like a headache! I'd say that this comment is especially relevant if you consider the situation where a framework can do all those different things, but in reality is only ever used for one very small and specialised set of tasks.
Personally I think it's a much better idea to implement a test driven approach, or at least one that includes proper unit testing, then you implement what you need, and refactor to include those "future features" as they become requirements.
Using proper OO, using interfaces and the like, and good designs should allow the refactoring of the code, to extend and expand it to fit new scenarios.

The big difference is that the solution then only implementing what it needs, and is therefore more likely to be tuned to those tasks, and be easier to maintain, and better performing to boot!

Service designs... People seem to have the wrong idea...

2007-11-05T16:18:00.000-08:00

I hear a lot of people talk about web services like they're something special. What I don't understand is why people think that. All that they are is an available transport to allow multiple platforms to talk to the backend.

The web service code shouldn't be in the web service, but should be calling into some sort of factory, or broker to get it to do all the work.

We should really view a web service as an interface only, so it's a different view, but a similar sort of concept to a web page, mobile page, windows application, or whatever.

Code sat behind forms, or services should be as minimalistic as possible, so that we can de-couple our implementations from the method that we use to move to that data around. There's no difference between this concept and the concept of an MVC or MVP implementation.

Architecting High-Performance, Reusable, Granular Services and SOA.

2007-11-05T16:13:00.000-08:00

Sorry people, but I don't believe the above is really a good idea at all.

You cannot write granular services that can perform well, in general. It's a shame that the selling point of SOA has often been this concept of re-usability... It is not! It is availability. You can access the service from many platforms, or that's the idea at least. The more technology specific the extensions you add to a service, the less you leverage the true power of SOA.

Managers particularly get to hear of SOA, and think of it as a great concept that will cut costs, save money and time, and generally be the answer to their prayers. Whilst it may be the latter, the other parts rely on an understanding of the technology. Writing services and expecting them to perform well, and be re-usable isn't going to happen, because in general you want your services to be quite specific to the problem that they address, to make them perform well.

Obviously if performance isn't a consideration, you'd probably be able to get away with granular services, but not for long! How many systems have you seen that started off as a few macros running on a users desktop application, and then becoming the company software platform, and having to attempt upscaling the solution?! What I'm saying is, if you're writing services, then that of itself should mean that the problem domain is complicated enough to justify the effort. don't do it, don't come up with a bunch of services such something to get a bunch of person records, then get a bunch of address records for a given person. Then you're going to try to munge them together, right? Please tell me you're joking! The whole process is over-engineered and would require so many workarounds that it's just not funny! Although I did have a giggle myself...

It's a much better idea to look at what you need, and how fast that needs to realistically perform, then come up with a solution that fits that requirement.

Generally speaking, distributed architecture means that you should be calling the backend only once if possible, to get better performance. If you're combining and consolidating services in the backend, you're introducing overhead and complexity that really isn't needed.

Can I get an Amen?!

Blogging starts again...

2007-11-05T16:12:00.001-08:00

Well, I've been offline for a while, but I'm back!

I'm going to devote some time to writing little blogs regarding software. I'm particularly interested in Architecture, Project Methodologies, and Development.

I'm hoping that there's other people out there who share my interests...

Martin.