The number of customers that might purchase your software has a detectable impact on how you develop that software. If you’re making a smartphone time-killing game, for example, there are potentially hundreds of millions of customers for that game. This drives software in two directions- you have your mounds of shovelware crap that just hope to make a few bucks fleecing suckers, and then you have the tight competition that optimizes the design of the software.

Contrast that to “enterprise” software. If you’re making an ERP, how many potential customers do you have? Thousands? Tens of thousands? And each one of them is going to want something different from your product, so you’ll need to either pile on features or build an Internal Platform that lets them customize it. It doesn’t matter how much money is in this market, or even how many users there are going to be- it’s all about the number of customers that might pay for your product. This, I suspect, is a large part of why enterprise software is terrible, and I think it lays out a corrolary to Remy’s Law of Enterprise Software: the narrower the audience, the worse the software is going to be.

Which brings us to the code sent in by Jason F. Jason recently finished a contract to “modernize a PHP web app for agricultural consultants.” About twenty or so developers have touched this application at one point or another, and Jason is simply the latest one through the revolving door. A niche market, a series of developers who have never talked to each other, and as the topper, it’s built in PHP.

One of the preceeding developers left behind this unusual approach to object-oriented programming in PHP…

    class AdvisorNewClient extends NewClient
    {
    ...
        //Client specific details
        public $licensee;
        public $advisor;
    ...
        public function __construct($licensee, $advisor)
        {
            $this->getLicensee($licensee);
            $this->getAdvisor($advisor);
            parent::__construct();
        }
    ...

        public function getLicensee($licensee = null)
        {
            static $id;
            if ($licensee) {
                $id = $licensee;
            }
            return $id;
        }

        public function getAdvisor($advisor = null)
        {
            static $advisorId;
            if ($advisor) {
                $advisorId = $advisor;
            }
            return $advisorId;
        }
    ...
    }

Good idea: having getter methods. Bad idea: having getter methods that force you to pass the value you want to get into them. Worse idea: masking the actual member variables with your parameters. This is the trick, here- you'll note that the parameters to the functions share the name of the member variables, masking them in scope and ensuring that they never get updated. If you actually tried to use these methods like they were sane methods, you’d be getting mysterious nulls, but if you just went right for the public members, you’d be fine.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!