This isn’t the first time I’ve started a new project where the client requires us to use certain technologies for its internal development. The company has its own department to meet its software needs (corporate website, intranets, ordering channel, ticket and incident management, and so on); now it needs to outsource some of that work.
It’s not that they use those technologies arbitrarily. The company’s own policy chose to invest in them and not move away from them without a well-justified reason. This gives all the internal applications a certain consistency.
That decision can be risky: what if we base all development on a database engine that eventually falls out of use or whose license price rises dramatically? What if we use this framework for web user interfaces and, over time, much better and more productive alternatives emerge?
Does anyone have a crystal ball that can predict the company’s needs years in advance? Phew…
Working on software projects that are expected to have a very long life sometimes means managing a great deal of uncertainty when choosing the best technologies for that project.
I say this often, and I won’t get tired of repeating it: using a library or framework well is almost more important than using the latest technology just because it’s new.
Here’s a simple example: I love Angular. It’s incredibly productive and lets you decouple many user-interface components so you can write tests for them. However, the new release, Angular 2, is a world apart from the previous version. So if you’ve built something with Angular 1.x in recent years, you know you’ll either have to keep using it for a long time or consider migrating to the new version, if that makes sense for you. And, naturally, from a business perspective, that migration costs money…
If part of a company’s success consists of mitigating and reducing risk, defining the set of technologies it uses for internal development can make sense. This approach isn’t exclusive to large corporations—not at all. Any organization, whatever its size, can adopt this policy.
What benefits could a so-called corporate framework offer?
Here are a few that come to mind:
- There’s no learning curve for new development: the team already knows the technologies in use.
- Since everything is based on the same libraries, languages, and so on, it’s more likely that components developed for other projects or applications can be reused.
- Maintaining the different applications takes less effort (or should), if a common approach to development has been defined.
- It’s easier to establish workflows, since they sometimes depend on the technologies being used.
In the case of this new client, they use ExtJS, PL/SQL (Oracle databases), and C# for all or nearly all development, along with clearly defined procedures for specifying, validating, and putting new development into production.
When defining a corporate framework, you shouldn’t judge anyone’s personal preferences. Instead, assess whether the technologies under consideration fit the company’s present and future needs.
On the other side of the scale are companies that use such a scattered range of technologies for development that maintaining everything eventually becomes a major obstacle. Just put yourself in the shoes of someone new joining the team who has to take on ten different technologies instead of a small, coherent set.