XML Orientation Tutorial

following are fragments from my article - available also at http://www.assistars.com

XML is a Markup Language.

XML stands for eXtensible Markup Language. If you've read through any HTML page source you probably know what markup language is about. If not read on - we will explain. Imagine plain text document - it is built from words, sentences, paragraphs, chapters. Now, if you would like to print this document and for example make some parts stand out from the rest of the text (by bolding them for example) - you need to provide printer with information to do so. The simplest and most effective way to achieve that is to put some special markers into the text (themselves being text of special meaning) which will not be printed out but will indicate printer to switch mode and print fonts with increased weight. Such 'tags' form a markup language. HTML was developed that way to enable annotating text presented on the web page with some formatting/presentation instructions. The very same idea is one of the foundation stones for XML.

There is more general pattern here: XML was built based on the ideas from HTML (as it was well tested and widely adopted format) but with different objective in mind: instead of using tags to provide information on how to display the data, let's use them to represent logical structure of the data.

Let's take a look at the example of XML:

<contact>
  <firstname>John</firstname>
  <surname>Doe</surname>
  <email>John.Doe@assistars.com</email>
  <phone country="UK">020 1234 4321</phone>
</contact>

First thing you may notice is that you understand the document from just reading it, it is pretty self-descriptive, the names of the tags suggest how content should be interpreted.

After brief reading of the example you may notice the following:

- tags are defined using '<' and '>' brackets like for example '' (similarly to notation used in HTML)

- for each tag we have corresponding 'closing' tag which is used to mark the end of specific element (by using '/' preceding the tag name) like for example ''

- elements of the document define tree-like structure (tags are nested) which allow to easily represent part-to-whole relationships among data. For example '' is a part of '' etc.

- by the names chosen for tags we can deduce that there are no limitations to how tags are being named

which leads us to next very important important characteristic:

XML is eXtensible.

There is no limits to the kind of information XML document will represent, and how it would represent it. It is your freedom (and responsibility) to invent your own tags and how to decompose your data into hierarchical structure. That's because you will be the one reading and interpreting it. Why it was impossible for HTML in which all tags are defined by the format? Because HTML had to be understood by general purpose browsers. With XML as long all intended data readers agree on format sky is the limit.

XML - the purpose.

The main purposes for XML is data storing and exchange.

Following characteristics made it very good for this task:

- XML is flexible - you can model pretty much anything you can think of, tree structures are powerful models for data representations (vide folders structure on the disk, hyperlink structures on the websites)

- XML is extensible - you can evolve your models as you gather or require additional data

- XML is text - as it is defined as plain text - there is no platform specific element to it - document is completely platform independent

- XML is human readable - you can understand it from reading it

- XML is simple - you understand the concept right away

And that's why this format was so widely accepted and adopted and made it to the standard.

XML - what it is and what it isn't.

It is important to take XML for what it is: a file format which accomodates hierarchical structure of data using tags to represent logical dependencies and meaning of the data. Nothing more. There is such a buzz around XML that people tend to take it for something more. XML itself is just a file format. Period.

Very powerful because of its simplicity.

Project Management - you can't go into many directions at the same time

One of the most important things in managing your project is to have a clear vision on what is it you want to deliver. Of course we all want to deliver maximum features with very low defect ratios, within 6 months time frame. I have news for you this is usually not possible. Those are interdependent and usually investing in one of the constraints costs you neglecting another. You will be making priority decisions throughout the project, so why not to get clear on what are them at the beginning. That would also give your team a clarity on what is important to the project and how to act when they would have to make priority decision themselves. So keep everybody in sync by providing priorities in advance.

As it always come to comparing two (sometimes more) project characteristics when you are supposed to make a decision I would recommend to write down an order of priority list which has the most important characteristic on top and then descend to less important characteristics.

So for example if you are targeting visionaries with new innovative project you know that you have to generate a specific minimal features set, release it as soon as possible, and think about quality later. You can reflect it in your list. That means that if your defect levels are high but you still don't have complete feature set you will devote your time to implementing features and not improving quality. Second important thing is to define what are the must-haves from the list - things which have to be accomplished for the project to be successful.

Now, make sure you are on the same page with your sponsors and potential customers as otherwise you are heading for disaster. You must be sure that list reflects priorities of people who fund the project. Talk to the sponsors and get them to choose what's the most important by simply asking them. If they don't want to choose as they want 'perfect quality, full feature set, 6 months, 4 people team' ask questions which will mimic decision you will have to make: "let's say it's a month and we still don't have full feature set and quality is low, shall we focus on quality or on features? Or maybe delay the release?". Do whatever you can to get it out from your sponsor. If you can't make the decision yourself (in advance) and get sponsor to agree, sign off on it. Without that project will be dead on arrival - overconstrained projects rarely are harder to deliver they usually are impossible to deliver. Unless you are Chuck Norris of course.

How to develop software faster

Nice article on how to develop software faster: here

Project Management Tips - Value Your Time

Tip: start be aware of where you spend your and your team time. Spend it wisely.


Steps to get there:

1. Once you reach the office, sit and don't start your machine for 10 minutes. Just sit there. Be careful with that - you may panic first few days. It's important you do nothing these 10 minutes. During this time you can think on what you would like to accomplish this day. Now for the scary part - before you get your emails.

2. Imagine time as a physical resource (imagine unit representative). Every time you are planning to spend some of it imagine how much of units you need to take from the heap of all units you have to complete the project and ask yourself: is it worth it? If it is then go for it. If it's not forget about it.

If you want to call the whole team (8 people) 2 hours meeting to discuss which variant of user interface workflow for some scenario would be better think again. Be creative in finding ways to make this decision at lower cost than two man days. Toss a coin for example.

3. Don't write elaborate emails. They look nice, but you have to pay a lot of time to write them, and then your recipients pay time to read them. Straight to the point is a good approach. People know you are smart anyway.

4. Don't answer your emails. Or less extreme version don't answer your emails right away. If you don't - problems magically tend to resolve themselves even without your attention. Don't worry if they don't you will be reminded about them. Extra benefit here: you minimize the risk of becoming your company's google search replacement.

5. Make sure that you open your mail program only once, twice a day - every 4 hours or so. Spend time with it, caress it for an hour or so, and then close it and start doing a real work. Limit your time spent with it to an hour, two hours a day. With that in mind your mails will be much more efficient.

Software Defect Reduction Top 10 List

I've just found interesting article on statistics behind defect reduction by Barry Boehm and Victor Basili: here.

According to the article top ten defect reduction list is the following (I'm citing the article):

1. Finding and fixing a software problem
   after delivery is often 100 times more
   expensive than finding and fixing it during
   the requirements and design phase.


2. Current software projects spend about
   40 to 50 percent of their effort on avoidable
   rework.


3. About 80 percent of avoidable rework
   comes from 20 percent of the defects.


4. About 80 percent of the defects come
   from 20 percent of the modules, and
   about half the modules are defect free.


5. About 90 percent of the downtime
   comes from, at most, 10 percent of the
   defects.


6. Peer reviews catch 60 percent of the
   defects.


7. Perspective-based reviews catch 35
   percent more defects than nondirected
   reviews.


8. Disciplined personal practices can
   reduce defect introduction rates by up to
   75 percent.


9. All other things being equal, it costs 50
   percent more per source instruction to
   develop high-dependability software
   products than to develop low-dependability
   software products. However, the
   investment is more than worth it if the
   project involves significant operations
   and maintenance costs.


10. About 40 to 50 percent of user programs
    contain nontrivial defects.

Software Quality Definition Revisited - Domain Landscape

Happy Year 2009 to everybody.

As new is coming I decided to add something new - a bit more structured to the blog. I will try to describe my understanding on what is on software quality map and where it fits. I will be tagging this thread with 'software quality landscape' tag

As described in my post ealier (here) Following are the software quality characteristics:

External characteristics:

1. Correctness - does software do correctly what it is supposed to?


2. Usability - is software intuitive and easy to learn and operate?


3. Reliability - is software working correctly when fed with correct inputs/environment condititions?


4. Performance - is software working within acceptable resource limits/response times?


5. Security - is software immune to attacks, does it protect data fed to it?
   Robustness - how well software behaves when fed with incorrect inputs/environment conditions?


6. Scalability - will software behave correctly and efficiently when fed with significantly increased volume of data

Internal characteristics:

1. Maintainability - is software easy to maintain?


2. Reusability - are software parts easy to reuse when developing another software which needs similar functionalities?


3. Portability - how easy it is to port software to other environments to the ones for which it was developed?


4. Extendability - how easy it is to add new features?

I will discuss all those in greater detail in subsequent posts in this thread ('software quality landscape').

C/C++ memory management - programs insanities listed

This is a continuation of my entry from several days ago view

There are different kinds of memory related issues, which usually lead to raise of a runtime error. Let's try to define categories of those:
- memory leaks - memory is being allocated and not freed, program 'grows' in context of memory usage somewhat proportionally to the time of execution, usually leads for program to become unresponsive over time. It is quite difficult to diagnose without having memory debugging monitors at your disposal.
- dereferencing nulls - we try to access memory behind the pointer which wasn't yet allocated - leads to access violation runtime error right away. Fortunately this one is fairly easy to diagnose as the cause is very close to the symptom.
- memory corruption - in our program memory there is a region which doesn't contain data we expect it does - it can be either because memory was never initialized, or because there was writing out of bounds situation on the neighboring memory region. Program now contains a 'mine' - as soon as we foot on it (by reading from corrupted memory region) we will get incorrect data fed to our program datasystem and it will start behaving inconsistently. Usually leads to runtime crash error, preceded by some strange and nondeterministic behavior in areas directly or indirectly dependent on data read from corrupted memory error. Like for the first category memory debuggers come handy here as well.