Archive for the ‘Technology Change’ Category

Congratulations BellKor’s Pragmatic Chaos!. You’ve earned your million and Netflix just became that much cooler.

I am an advocate of open-source software. Indeed, we deploy (almost exclusively of late) many different open-source software solutions for our clients and our own projects. But I often run into issues when talking about open-source software with clients, and it sounds a little something like this:

Client: Isn’t there an open-source product that performs that function?

Me: There are a couple of products that perform the same operation, yes.

Client: Well, why do I have to pay for something that’s already been done and is open-source?

And so it goes. If you’ve ever developed software using open-source solutions (and my guess is you have), you’ve undoubtedly run into the same tortured logic around the myths of open-source software.

Open-source software is free.
Sure, you can download them for free, install them for free, and deploy them for free, but thats about all you can do…for free. Once you need to work them into a cohesive project, they start to cost you time or money. It’s true that good open-source solutions can lower your costs. For example, the restful_authentication plugin from Rick Olson makes it quick and easy to implement an authentication function in a Ruby on Rails, but restful_authentication alone does not make a complete system. It’s always part of a larger application and using the plugin saves the developers time and the client money, but it must be integrated, and that will always cost time or money.

Open-source software is the complete solution.
This is rarely the case. Even when you deploy a Wordpress site, you still need to create the theme and customize the installation (even slightly) and that’s going to cost money. It will definitely save you a ton of development costs to launch a Wordpress site instead of rolling your own CMS (I know some people debate whether or not Wordpress is a true CMS), but it still costs money. This fact is exaggerated even more greatly when you’re building a custom application in Ruby on Rails or CakePHP. There are literally thousands (maybe hundreds, I’ve never counted) of open-source plugins available for both frameworks, but they solve particular problems and hardly ever make up a complete application.

Open-source software is high quality.
This couldn’t be further from the truth. In fact, I would argue that high-quality open-source software is far more rare than people think. Any Tom, Dick, or Lisa can create an open-source project and release into the wild. It doesn’t have to be tested, and it doesn’t even have to work. To declare something open-source, all some has to do is say it is so (like we did, but PopCrit is well tested). No testing is necessary. While I do agree that the community votes with their feet, they can’t vote on everything so there are a lot of unknowns when using an open-source solution in a project. Choosing one solution over another could be the worst decision in the entire project, and cost you and the client even more time or money.

There are probably even more myths, but I think these are the most pervasive and caustic for custom software developers. I am a true believer in open-source, but not for the reason that they save money or effort. I believe in open-source because, every once and while, the projects can change the direction of entire industries (MySQL), and from time to time, they save me time and energy.

-Chris

The video speaks for itself.

So, I’ve decided it’s time to reinvigorate www.integratechange.com, my company’s home page. But I never like to do anything if I’m not learning something, so I’m shifting gears for integratechange.com. I’ll be building the site using the Konstrukt framework. It seems to be light and requires more programming effort than Rails (which I think is a nice thing to do if you code for a living).

I’ve been doing most of my work in Ruby on Rails. Both Event Clipboard and the Marketing Site for Event Clipboard were built in Ruby on Rails. And I have to say, I absolutely adore Ruby and I have enjoyed the process of developing in Rails. But a few things have really been getting to me lately.

1) Rails is heavier than I’d like. It includes almost everything you need to write a web app. That includes all the plumbing to get data to and from your database…which is nice. Sometimes, though, I just want the bare minimum to get the job done, and I find that the plugins that make up the infrastructure for rails are cumbersome and encourage lazy design. For instance, I consider the attachment_fu plugin is my nemesis and encourages too much back and forth to the db (in my opinion). This heaviness should be much improved as Rails and Merb merge to form a more lightweight framework in Rails 3.0.

2) Rails development can be too lazy…and this is my biggest complaint. If you’re not careful in Rails dev, you can produce a sloppy application that seems like it works, but will ultimately become a performance nightmare. I’ll avoid talking about apps I’ve been involved in too protect the innocent, but suffice to say, I’ve seen some doozies.

I came to Rails from .NET where I wrote every single line of the application, the Data Access Layer, Business Logic Layer, etc, etc. 50-60,000 lines of code and a superb attention to the database and the superior power of SQL to access data. Rails was definitely a welcome reprieve from all of that coding, but I fear that I’m getting soft. I also don’t like to be a one trick pony, so I’m focusing this redesign using a RESTful framework in PHP. It’s been a little bit since I built something in PHP and I was always a fan. It’s good to get back to it.

I’ll be posting more here as I learn about the framework from our good Danish friends.

-Chris

Well,

I finally buckled down. I’m a Mac owner. The Macbook Pro 15-inch. I have to say. I am certainly impressed with the whole get-up. My first thought when I opened the box was…They sure know how to make an entrance. That feeling continued when I started it up for the first time. Nice work. Of course a lot of people already knew that.

Now for the hard work. Because my business is software, there’s a ton of stuff and software I have to put in place to make everything work for me. IDEs, subversion clients, programming languages, etc., etc. It’s going to be a long slog to get it where I need to, but for the early signs are still pointing to a fairly easy transition. Thank you to Apple for switching to Intel processors.

Later this week, I’ll be installing Vista with Bootcamp. It’ll be interesting to compare the two OS’s having just left the comfortable world of XP.

-Chris

Windows 7 Beta Preview

For those Xbox 360 fans

I may be one of the only people who admits it, but I like the looks of both.

-Chris

Identifying opportunities is paramount to business success. The faster a company can understand its internal landscape, the faster it can capitalize on an opportunity. We believe that great information management systems put easy to understand, contextual information at the user’s fingertips. At Integrate, we accomplish this through systems that manage day-to-day activities (e.g., invoice payments, budgeting, etc.). We‚Äôve noticed that these systems provide a clear view into the health of the organizations they serve. This clarity can produce a secondary side-effect, transformational change – change that affects the culture of the organization.

This happens for a couple of reasons:

• First, the system generates enough efficiency, employees become more effective, utilizing their time on value added work.
• Second, and more importantly, visibility to important data allows for more in-depth analysis of an organization's business.

It‚Äôs fairly obvious that employees who spend less time doing mundane tasks can and will add more value to an organization. However, less obvious is the effect of data visibility. I’ll use the example of a spending and budget management tool. Let's say that for the first time, an organization has a clear picture of how much they have spent on external technology services against how much they have spent on their own IT department. If the tendency of the organization is to spend more on external services than their own internal department, that may prompt the organization to begin asking important questions: Should we implement more professional education initiatives? Do we need to hire IT professionals with more diversified skill sets?
Is our IT department aligned to work efficiently? Should we eliminate all or part of the department in favor of external vendors?

There are a myriad of different outcomes, large or small, that can come from a thorough analysis of the spending discrepancy. For example, the company could decide to route money spent on external contractors into professional development for the in-house IT department, which in turn may create a culture of employee development. Conversely, the company could eliminate its IT department and focus on its core business. While not transformational in and of itself, effective transactional change can provide a window into an organization’s strengths and weaknesses and ultimately shine a light on opportunities.

It’s been 32 years since Frederick P. Brooks, Jr. wrote The Mythical Man-Month. So, after such a long time, why is over-management and over-staffing still ruining timelines in software development. Aside from the book’s general development advice, which may indeed be slightly antiquated and apply to systems with 100’s of thousands of lines of code, the gyst of the book’s title essay is that adding developers or project managers to a project behind schedule will not only make a project miss its target release date but will probably result in a sub-standard product.

For those not familiar with the idea, here’s the Cliff’s notes version from Wikipedia (I can vouch for its veracity):

Assigning more programmers to a project running behind schedule will make it even later, due to the time required for the new programmers to learn about the project, as well as the increased communication overhead. When N people have to communicate among themselves (without a hierarchy), as N increases, their output M decreases and can even become negative (i.e. the total work remaining at the end of a day is greater than the total work that had been remaining at the beginning of that day, such as when many bugs are created).

• Group Intercommunication Formula: n(n ‚àí 1) / 2
• Example: 50 developers -> 50(50 ‚àí 1) / 2 = 1225 channels of communication

It makes sense when you read it. The more people you have on a project, the more complex the communication and subsequently the entire project becomes. It’s probably no secret that Integrate runs really light project teams, sometimes with only two or three highly skilled individuals for even incredibly complex systems, so we have a bias toward small nimble teams. We’ve learned that keeping our project teams lean allows our developers to get closer to the client, in most cases the developer is the lead for the project team. This eliminates any communication nightmares.

So we implore all managers to resist the urge to add bodies to a late project. It seems like the best idea when you’re running out of time, but all you’ll only really spend more money faster and the project will still be late. Your best bet is to find the one or two best developers on the project (of course, this depends on the project’s size but you get the idea) and let them finish the work without all the extra headache of communicating and documenting everything they do.

Very interesting article regarding ROI and investment in technology. It’s worth a read if you’ve ever stumbled over making your case for high quality technology investment.

IT Value Metrics: How to Communicate ROI to the Business

…research shows that companies that have managed the complexity of their IT by building well-conceived systems rather than throwing a lot of technology at the wall to see what sticks get higher value from their IT spend…

It’s been a while since we’ve posted anything. We’ve had one of our busiest year-ends to date, and the first thing to go by the way side is our blog. Our apologies to our readers. We’ll get back on the horse shortly.

It’s difficult to get buy-in or acceptance when launching a new technological solution at any company. The issue is compounded at large companies when the solution is global or cross-functional in nature. At Integrate, we found a back door to large scale buy-in. It seems only fitting that we pass on a few secrets of our recent successes.

What we’ve discovered is that targeted, useful, and thoughtfully designed applications have a life of their own. Our clients are typically small groups within large organizations. They have an operational need that can’t be filled by their busy tech department, so they come to us. As a result, our projects often entail the development and implementation of highly focused and flexible applications for smaller user populations. We’ve noticed that this emphasis on incremental change for smaller groups increases the user acceptance rate because it’s easier to control quality and decreases response time when issues are discovered. Increased user acceptance, in turn, does a couple of rather remarkable things for an internal application: it creates an ecosystem around the application that both supports and enhances its operational effectiveness, and establishes an environment in which the system itself becomes an integral part of the group’s daily activities. In the end, the new application is successful – not because of genius coders, but because of exceptional relationships.

Successful applications very quickly become part of a group’s day-to-day activities and news of improved operational effectiveness spreads through word of mouth. This often peaks interest around the company – particularly within other groups that perform similar functions. What develops at the end of the day is a very natural and organic adoption of the system by new and different groups. This may involve slight re-development of the application to encompass new permissions, functions, etc., but the system’s previous success typically frees budget dollars for additional development. Thus, the ecosystem grows larger with each new user base and the application continues to grow and change as new individuals enter the conversation. Over time, this ecosystem begins to organically include new groups in other regions until the application is indeed global.

We’ve seen this pattern repeat in more or less the same fashion over and over again. So much so, that we began to wonder how we could harness this ecosystem to improve application adoption going forward. Although we’ll never have a cookie-cutter solution (as that would belie the idea behind building unique relationships that develop great software), we have some simple rules that developers and change agents can follow to lay the ground work for this kind of incremental and viral change.

First – Exceptional Design. It must all start with exceptional design. I use the term design to describe not only the flexibility of the system architecture, data structures, etc. but also the user interface. No matter how good your architecture is, it has to be easy to use and to a slightly lesser extent, pretty. An attractive design communicates professionalism and reliability. Avoid this fact at your own peril.

Second РSmall Target Audience. Devote your efforts, at first, to a small target audience. This will eliminate lots of noise from requirements which will hopefully, in turn, produce a cleaner design. This doesn’t mean ignore the larger organization or the possibility of growth, but it does mean that you can proceed more confidently toward an effective design. It’s also a lot easier to manage a smaller set of stakeholder relationships.

Third РThis is not a Proof of Concept. This may seem like it’s a dry run for the whole organization, but make no mistake. The more energy you put into developing a true and effective solution for the target audience, the more word will get around. “Proof of Concept” connotes something that will be thrown away in the future. This will not create an environment where users attach themselves to the system.

Fourth РBuild a Long-Term Honest Relationship. Even if the project plan calls for the phasing out of the development team, build the client/developer relationship like you’ll be friends forever. This plays a huge roll in acceptance. If the developing group/company (i.e., Integrate) is seen as a disinterested outsider bent on pushing out their newest solution…feedback will be less honest, the application will suffer tremendously, and adoption will only happen begrudgingly.

Fifth РBuild Quickly and with Great Quality. Build as fast as possible and make sure it’s the best it can be. This doesn’t mean it won’t have bugs, but it does mean you’re dedicated. Dedication goes a long way. Even more importantly, deal with bugs even more quickly and with even greater quality. In other words, don’t make the same mistakes twice.

These are not hard and fast rules. These are general practices we follow at Integrate that work for us and our clients (they keep coming back for more, and to them, I say thank you). Ultimately, you could make this into an even more structured model with the goal of managing global change. For now, we’ll keep our focus small and our thinking big.