No wonder your surprise to learn that such thing ,as a CMMI Certification, does not exits! Software Engineering Institute (SEI) of Carnegie Mellon University issues a meager “appraisal”. Well, you might say, appraisal, certification what’s the difference? In the end, it’s the same thing and to reason to make a fuss about it.

Let’s see what does SEI has to say about it:

“The SEI does not certify the results of any appraisal nor is there an official accreditation body for CMMI. True certification of appraisal results would involve the ongoing monitoring of organizations’ capabilities, a shelf life for appraisal results, and other administrative elements. When an organization is appraised against the CMMI model, their Lead Appraiser’s findings may indicate that the organization is operating at a particular “maturity level.” The SCAMPI appraisal method maturity ratings are 1 through 5.

The SEI does not have a defined requirement for periodic follow-up after appraisals, nor does it accept legal responsibility for the performance of appraised organizations. All of these characteristics are required for a program that would provide certification of appraisal results. However, CMMI Appraisal results do expire after a period of three years.”

Source: SEI website

While difference is subtle, it is by no means innocuous, as it is explained clearly on the SEI website. SEI does not accept any legal responsibility for performance of companies they awarded appreciation report nor does it monitor them directly.

As you can see, the choice of words was not random, but carefully made. No reason then to be surprised by reports (and here) where companies that get CMMI “Certified” use only one department or team on order to get the logo, where companies after certification soon go back to old ways, where only motivation they have is winning a contract or a tender etc. Ever heard of the LCPBCs? If not you can google it, I will not spoil the fun

In the end, one can not but wonder how come that some agile circles were not able to avoid the certification trap, when even some of the organizations that inspired the whole movement, were smarter than that?

It’s NOT OK to cut corners, but it’s OK to cut features.

I guess that sums a great deal that agile development is all about! You do very short iterations but you do them properly (no cutting corners). Once you start with new iteration, your client can invent new, eliminate old, reprioritize all features etc. (This is what I actually mean by “cutting features”.) As it happens, most of the time the client will realize that some features are not needed, that other are, and will accept that he can live without “nice to have” as long as the core features are done right and without bugs. As a matter of fact, it is difficult (no to say impossible) to know all the features you will need right at the start of the project. So, why should you cut corners to deliver a feature you are not even sure it’s needed? This doesn’t necessarily have to do with 80-20 rule, it’s more of looking at the software as the “work in progress”. You can release the first version once you have implemented the minimum set of core features that do something useful.

Once you and the client change the mentality from “features initially put into the contract” to “real business value delivered”, you will have no need to cut corners. Switching to short iterations and having users participate in planning and accepting results of each feature had a profound effect on how my team is operating and had enabled us to really uphold the quality aspect of software.

Only a decade or so ago, general approach was quite different. You’d try to make your system as encompassing, flexible and configurable as possible. You’d design your system for tomorrow’s needs.

I will give you a quick example. Imagine you need to program a feature on your website where you export some data to an excel file. In the old days, you’d analyze the problem, design your classes let’s say in a form of hierarchy where ExcelExporter and PdfExporter inherit BaseExporter class. You do not need to export data to pdf just yet, but you think you might need it some day, so you better be ready.
These days, however, you live in the present. You just program ExcelExporter. If one day you need pdf export feature, you will reorganize your classes so that both ExcelExporter and PdfExporter inherit BaseExporter class that contains some features common to both child Exporter classes so you can avoid duplication. If you never come to need this feature, you leave your ExcelExporter alone. You will implement new features as they are needed: just-in-time.

But there is a catch. In order to be able to move just-in-time, you should have a well designed, mercilessly refactored code covered with tests. Without refactoring or automated testing you are probably better of doing things the old fashioned way.
I think YAGNI is great and I try to follow YAGNI mercilessly. However, sometimes I hear YAGNI principle invoked in a way that it is clearly misinterpreted. For example “Maybe you do not need to refactor this code just yet” or “Maybe you do not need all those unit tests”. Thing is, to be able to do YAGNI, you need to have your code refactored and covered with tests. You need continuous integration and automated builds. Without these practices, once you need to implement a new feature in JIT fashion, things will inevitably start to break. One way to avoid “Maybe you do not need good quality software” kind of dilemmas is to make practices like TDD, refactoring and continuous integration integral part of your development process. Then, there is no need to think that you might leave out unit tests; since you are doing TDD these are in place already; since you refactor all the time, then there is no way to leave it out.

Remember, YAGNI applies to features, not to quality! One way to use YAGNI properly is to think about Technical Debt. Is the decision NOT to do something resulting in Technical Debt? Technical Debt has to be payed off with interest and with software rates are extremely steep. If you are getting into debt, you are not YAGNI, you are plain’ SLACKING!

[Table()]
    class Customer
    {
        private Address address;

        [Column(IsPrimaryKey=true, IsDbGenerated=false)]
        public String SSN
        {
            get;
            set;
        }

        [Column]
        public String FirstName
        {
            get;
            set;
        }

        [Column]
        public String LastName
        {
            get;
            set;
        }

        [Association(ThisKey="SSN", Storage="address", OtherKey="SSN")]
        public Address Address
        {
            get
            {
                return address;
            }
            set
            {
                address = value;
            }
        }

    [Table(Name="Customer")]
    class Address
    {
        [Column(IsPrimaryKey = true, IsDbGenerated = false)]
        public String SSN
        {
            get;
            set;
        }

        [Column]
        public string Street
        {
            get;
            set;
        }
    }

        static void Main(string[] args)
        {
            DataContext context = new DataContext("Data Source=XYZ;Initial Catalog=TEST;Integrated Security=SSPI");

            Customer customer = new Customer{
                SSN = "123",
                FirstName = "First",
                LastName = "Last",
                Address = new Address{
                    Street = "My Street",
                    SSN = "123"
                }
            };

            Table customers = context.GetTable();
            customers.InsertOnSubmit(customer);
            context.SubmitChanges();
        }

//DB DDL
CREATE TABLE [DBO].[CUSTOMER](
        [SSN] [NVARCHAR](50) NOT NULL,
        [FIRSTNAME] [NVARCHAR](50) NULL,
        [LASTNAME] [NVARCHAR](50) NULL,
        [STREET] [NVARCHAR](50) NULL,
 CONSTRAINT [PK_CUSTOMER] PRIMARY KEY CLUSTERED

As you can see, a single Customer has a single Address. Customer with corresponding Address maps to a table Customer. Everything works well, until you try save new instances. You get the following error: Violation of PRIMARY KEY constraint ‘PK_Customer’. Cannot insert duplicate key in object ‘dbo.Customer’. If you try to execute the code and you should be able to reproduce the error.

Solution

In the end, it is all just about method call order.
The solution is the commit the root object first (Customer) in our example, without related object (Address). This way, the instance of related object is created also, with all properties empty.
Second step is to set the properties of related object. Here the important detail is not to create the instance of related object, since it has been already created by linq2sql. Then, you commit changes again and this time the related object is also updated and saved.
It would probably not work if you had to enforce not null constraint on some of the related object properties.

Here is the same example fixed to work without error.

class Program
    {
        static void Main(string[] args)
        {
            DataContext context = new DataContext(
                "Data Source=XYZ;Initial Catalog=TEST;Integrated Security=SSPI");
            Table customers = context.GetTable();
 

            Customer customer = new Customer
            {
               SSN = "SomeSSN",
               FirstName = "First",
               LastName = "Last"
            };
            customers.InsertOnSubmit(customer);
            //Save customer first, this will also create the Address
            context.SubmitChanges();   

            //Now Address is not null anymore, so it will be updated
            //Linq2SQL will not try to insert new row
            customer.Address.Street = "Updated";
            context.SubmitChanges();

            //get one instance for demo purposes
            Customer saved = (from all in customers
                                 select all).First();
            Console.WriteLine(saved.Address.Street);

        }
    }

    [Table()]
    class Customer
    {
        private EntityRef
 address;
 

        [Column(IsPrimaryKey=true, IsDbGenerated=false)]
        public String SSN
        {
            get;
            set;
        }

        [Column]
        public String FirstName
        {
            get;
            set;
        }

        [Column]
        public String LastName
        {
            get;
            set;
        }

        [Association(ThisKey="SSN", Storage="address")]
        public Address Address
        {
            get
            {
                return address.Entity;
            }
            set
            {
                address.Entity = value;
            }
        }
    }

    [Table(Name="Customer")]
    class Address
    {
        [Column(IsPrimaryKey = true, IsDbGenerated = false)]
        public String SSN
        {
            get;
            set;
        }

        [Column]
        public string Street
        {
            get;
            set;
        }
    } 

//DB DDL
CREATE TABLE [dbo].[Customer](
        [SSN] [nvarchar](50) NOT NULL,
        [FirstName] [nvarchar](50) NULL,
        [LastName] [nvarchar](50) NULL,
        [Street] [nvarchar](50) NULL,
 CONSTRAINT [PK_Customer] PRIMARY KEY CLUSTERED

What got me thinking about it is a bug I investigated recently that had to do with two base java classes: java.net.URL and java.net.URLConnection. The symptom was a generation of leaking file handles, resulting in server hanging after few hours of operation.

Take a look at this java code:

           URL url = configuration.getURL();

           URLConnection connection = url.openConnection();

           long date = connection.getLastModified();

Now, I’d typically put method open on the connection object. If you take a look at URLConnection, you will see that the class does not have the close method. That’s all right, following the symmetry principle, it would be then consistent to place closeConnection method inside the URL class. Alas, neither the URL has the method that closes the connection!

This was the source of our bug. The programmer had to open the connection in order to read getLastModified. But, since neither URL nor URLConnection had the close method, he “forgot” to close the connection. The solution is to do the following after reading the date:

InputStream stream = connection.getInputStream();

stream.close();

No wonder the programmer forgot to close the connection; there was no obvious method he could call to do so. I haven’t bothered to take a look at the code of these classes, but it seems unlikely that there was no other option when designing them. Had the authors thought about symmetry when creating URL and URLConnection classes, a nasty bug could have been averted.