Businesses that rely on development resources of their own often look at technology as an enabler or a means of separating themselves from what is otherwise a nondescript industry. A wholesale business of nuts and bolts might “enable” themselves by touting efficiencies due to their high-tech inventory/ordering system. One nuts and bolts business can very well be exactly like another, save the target market, but one that leverages high-tech development to reduce costs can easily differentiate itself from the pack.

For those who inhabit the realm of business-level development, rather than the deeper, more turbulent end of the technology pool of pure technical development businesses, what can seem like a safe environment hardly matches the reality. In the waning days of the DotBoom of the 90s, leading up to the DotBust of 2001, securing or keeping your job was as much attributable to luck as your technological skill. The luck came from the business leadership, the second biggest lottery in the business world right after customer perception. If the business leadership was smart and saw the value your organization contributed to the bottom line, you had a better than average chance of keeping your job.

The problem with the business seeing the value of the development organization stems from the fact that most development organizations are a cost center. Products and services that come out of the development organization may or may not turn a dime into a quarter, but the development organization costs money everyday. This groups the development organization with other groups that incur a cost, like Human Resources, where the necessity is perceived, but the value is hard to quantify and outsourcing challenges abound.

The point to all of this is development organizations stand a better chance of surviving and flourishing when it can show its worth qualitatively as well as quantitatively by tackling business issues through technology smartly and at the best cost possible. This means processes must be examined, technology strategies must be set and adhered to, and skill sets must be improved, all with an eye towards improved cost efficiencies. Development designs and methodologies must be geared to better flexibility and maintenance must be easier. Project management methodologies must be cautious of monolithic processes. Development skills need to be observed as craftsman skills, where the product or service being developed should be seen as a custom car or house. When these skills are not kept up to date, serious cost overruns can occur due to poor execution. All these points add up to an image business leaders can have of development as a money drain when a downturn in the economy occurs.

This is the essential progenesis of Bu$iness C0de. Analyzing the different aspects of technology in the business world to find ways to better address business needs.

It might be stating the obvious that development is a rather fluid process. Few projects are ever “finished”, especially in businesses that are not inherently technical, but rely on technical process to en able the business. As they use the product, and as business changes, the software must also adapt in kind. Aspects of the business may find new uses for the same software, but that adaptation will often incur a need for further development. Depending on how well organized the Development group is, this ongoing effort of development will have varying degrees of pain associated with it. Two well-developed processes in the industry endeavor to reduce this pain: continuous integration and unit testing.

 Unit Testing takes the component-based architecture to heart and builds on the foundation that comes from. A component should be based on a concern of some sort. It may expect some input and, based on that input, it should exhibit some behavior or achieve some output. So, by this standard, you can establish a test that offers some specific input and test for the expected output. The test would be predicated on the requirement of the feature. When the code changes, and the requirement hasn’t, and the code passed the test before the change, if it fails after the change, you know something is wrong. If the requirement changes, and some will, then you change the test first, then you change the code to pass the test. This is much more like a “Ready, Aim, Shoot” response to challenge the normal “Ready, Shoot, Check the Target” effort that plagues a lot of companies.

Continuous Integration takes the effort of the unit testing one more step. Unit testing must be enforced each time the code changes, as soon as it has changed. One of the biggest problems in projects of all sizes and for maintenance efforts is that changes to code that eventually cause a break are harder to find the later they are found. If something got changed, but it wasn’t tested until a week or two later, and a number of other things got changed in the meantime, then it becomes a hunt to find the bug. But if you could find the results of the changed code immediately, then you would know exactly where the problem was.

This becomes a good bit more difficult in practice when you have a dozen developers all working within the same code, especially on a tight time schedule. The continuous integration effort utilizes a system that will scan for changes in a set area within the source code repository, and once a change is identified, it will automatically pull the entire project down, build, test, and report the results. It can be set to notify team members of the build results and processes can be built around these results to ensure everyone is informed of issues before they become nightmares. There are several systems of this type, some open source and some that can be purchased. Most of them are flexible on the repository and unit testing flavor, though some are specific to the programming technology, i.e. .Net rather than Java and vice versa. The gain out of all of this is a level of control over changes in a project that weigh a team down, reduce productivity, and tighten timelines even further.

The site has been updated to v1.6.0.5, with Captcha integration and Disqus comment support. For now, I'll be using Disqus. Thanks to Ruslan Tur at BlogEngine.net for the update.

Welcome back to the first post of Bu$iness C0de. We had a bit of interruption due to a migration to WIn2008 and IIS7, but we should be squared away now.

The basic purpose of this blog is simply to examine how design and coding efforts affect, and are affected by, business direction. Plenty of developers (as well as business people) would be satisfied with the idea that developers should do their own thing and business can do their own thing, without giving thought about how this perspective is antiproductive. Everytime I hear about a failed software product or initiative, I wonder about how the developers and business owners communicated through the course of the effort. The same goes for each report of a company outsourcing their entire development staff (or entire IT for that matter) as this always amazes me how a business can look at development/IT as a commodity.

I'm not saying that parts of IT cannot be commoditized. I was part of a team back in the 90's that helped run Owens-Corning's IT resources (servers/email/etc) remotely. This effort was proof of just how easy it was to lump this kind of service like so much corn and orange juice. But this service had a personal aspect to it as I remember working with people at OC by name on a daily basis. That's a quality you don't normally get from a commodity.

I guess you could look at it more like an auto repair shop. It's a specialized service and there are plenty of them around. But when you find one that really provides you the level of service you expect, this auto shop becomes 'Your' auto shop. They know who you are by name when you come in and they have your best interest in mind constantly. Coming from a small town in Texas, my grand-dad owned an auto shop just off the town square. He started that business shortly after returning from WWII and the shop was still open when I was a little kid back in the 70s. For years after the shop had been sold off, when I would go back home, people would still ask "Aren't you J.E.'s grandson? You know, J.E. had that garage and he used to work on my Buick..." That's the kind of affect service can have on a business relationship. I have that relationship with my auto shop now here in Georgia. They have been working on my vehicles for the last 12 years or so and their service level is incredible by anyone's standard. I know the guys who work there by name and they know me. I would be hardpressed to call what they provide a commodity.

I have the same opinion about IT services, in general, and Development more specifically. But the maladies I find are on both sides of the coin. Businesses (not specifically in the Technology sector) often sell IT services short by saying "Well, we're not a technology company. We just use technology to get the job done." IT does something similar, but more from the angle that "Business doesn't get us." These kinds of mentalities prevent positive conversations. Hopefully by training a light on these perspectives, parties on both sides can find a better way to move forward.

Full disclosure: I am a software architect for a private corporate firm. My viewpoints will always begin from the Development side of the argument, but my job requires that I look at what is needed, strategically and tactically, and make recommendations about what is best for the business. I push my development group with the knowledge that as the group improves, the business will see the results in the bottom line.