When a new version of a framework or language appears (e.g. .NET 3.5, SQL2008), what approach do people take to when to adopt/upgrade?
Generally developers will say as soon as possible (they want it on their CV and from a management perspective giving them what they want provides a motivation boost) but commercially there is often little incentive (few clients demand the latest version) and from a cost perspective (retest, training) there is often a disincentive.
I'm particularly thinking of "on-going" systems and projects (such as in a software house) which exist and evolve over years where taking the "new projects use the new technology" approach doesn't work.
Are people driven by specific requirements (the need to use a new feature, a potential or existing client demanding support for it), do they formally assess it (in which case what are the criteria) or do they upgrade as a matter of routine (in which case when - leading edge vs. bleeding edge)?
Do people think that not being on the latest version of something should be considered technical debt and managed as such?
Or is "if it ain't broke don't fix it" a valid approach?
Read up on Technical Debt. This is a simple cost-benefit decision.
The "if it ain't broke don't fix it" is a common management policy that says "tomorrow's dollars aren't worth as much as today's, so don't plan for future improvements." Eventually technical debt accumulates to the point where the product can no longer limp along.
The most common breaking point is when some piece of the infrastructure is no longer supported. By then, incremental change is impossible.
Reinventing from scratch is a new capital investment. Fixing existing code is an expense. The accounts force management to make technically crazy decisions.
In the case of open source software, it requires careful technical management since there's no official "support sunset" announcement from Oracle/Sun. Bad technical management, of course, leads to technical bankruptcy.
We look at the support lifecycle costs. For how long are the older versions supported, and at what costs? Platforms like Windows and Java tend to move fast as compared to mainframe environments, and part of the cost of doing business on those platforms is to perform periodic upgrades. In a rational world, that is!
New versions can have killer features we need -- but that is rare in enterprise development. The main positive selling points of new versions (as opposed to negative ones such as expired support) tends to be greater developer efficiency, which is hard to measure. Against that, as you indicate, the cost of retraining must be considered, not only for the initial developers, but, crucially, for maintenance. In each upgrade, some applications tend to be left behind as too critical to retire, and too expensive/fragile to upgrade. Over time, the number of platforms and versions you have to support increases overall technical debt (no matter their age).
Another criterion for upgrading to new versions (which you note) is the ability to attract and retain staff. With the current economic phase, that's playing second fiddle, but still cannot be ignored completely. You want to have at least a seasoning of enthusiastic and knowledgeable developers.
I think the killer question is whether your app will survive long term if you NEVER upgrade the platform/language version. If you think it can't, you may as well upgrade sooner rather than later, as it will only become harder.
Think about how long your app should be actively developed until you need a full rewrite. If you never plan to rewrite it, I would upgrade continually. Consider how difficult it will become to find the best developers if you are working in an outdated technology. Consider how new framework/language features could speed up your development process in the long term, for a bit of short term pain.
When you really need to. .NET 1.0 was crappy, 1.1 was a nice upgrade, but Web development with VS2003 was not so smooth. Things improved with VS2005 and .NET 2.0 – and I see still many developers and companies are stick to .NET 2.0. Previous versions were so fresh, version 2.0 was mature tech. So, if you were happy with 1.1, why would you upgrade? If you are happy now with 2.0, why upgrade to 3.5 or 4.0?
When the benefits of upgrading (more features, or a bugfix you need) outweigh the risks/costs involved (new issues, breaking existing code).
When you develop for Microsoft based platforms, like a Windows Forms App for Windows or ASP.NET webapp for Windows Server, the nice time to migrate is for every two major versions of OS.For example, if your app has been developed for Windows 2000, you ought to migrate to Vista though XP can be neglected. Similarly, if it were designed for XP SP2, you can safely ignore Vista and target Win 7. Usually Microsoft never breaks (or rarely breaks) incremental OS updates. So an app running on today's OS will definitely run on the next. But never on the one following it. (It if runs how can M$ make money???)
Source: Self... Windows Developer for over 5 yrs)
I'm in the upgrade as soon as possible camp (though I might wait a month after a new version come out just in case for uncaught issues). There are a few things you need to think about:
1. Security Releases
Many of the people who tell me if it isn't broke don't fix it are also the same people who would close their 2 eyes when security patches get released. Think Equifax.
To me it is an ethical responsibility to at least be on security supported versions of a framework. We owe it to our customers to safeguard their data.
2. Attracting & Retaining Talents
There are lots of talk about how the programming language or framework used doesn't matter. But in my experience, the cleanest code and design for a web app are usually written by the people who are passionate about the framework & programming language used because of their experience & expertise with it.
These people are unlikely to stay around for long or join your company if you stick to a very old version. Please think about your developers' happiness.
3. Newer, simpler ways offered by the newer version
Very often newer versions of a framework make something hard in the past much easier. If we do not upgrade, we miss out on the good new packages/features and we write our code in the old frustrating way knowing there is a much simpler way to achieve the same feature. And when it comes time to upgrade, we may end up having to change again to the new way. So why not upgrade and use the new better way and waste less time?
Related
I have often wondered why MySQL has become so popular. Any ideas why? Are there specific reasons behind its success? (Please keep answers analytical)
It is free, which means it sees more use on personal projects as well as on hosting platforms that provide a DMBS solution.
It is one of the few solutions that can run on almost any operating system.
It uses basic SQL rather than a specialized variant, meaning that it requires less-specialized knowledge to use.
Setup and configuration is more straight-forward and less time-consuming than most other options.
added more spices, is pretty fast for myisam
for what is meant free
if you using oracle, and you want to setup multiple instances on different boxes, you probably required to pay for each boxes.
unless, you have big budget to spent, oracle just don't sounds great
postgres is also free
mysql is easier to learn due to it's friendly sql (not standard compliance)
Early support in languages like PHP had a bit to do with it as well. While MySQL's C API is relatively straight forward (provided you are comfortable managing your callbacks), the PHP implementation made it crazy easy to use. Some would argue too easy to use.
I've worked in the hosting industry for quite a while, and notice trends. Almost as soon as PHP added support for SQLite3, people started asking for it to be installed. I'm not saying that PHP is the only contributing factor, nor can I guess at just how much of a factor it was, but it did have a bit to do with it.
After all, they call it LAMP for a reason.
It's opensouce and free (Community Edition).
Ubiquity, cost and performance.
Open Source - free of Cost [GNU license] - It is one among LAMP Linux, Apache, MySQL and PHP. So Its is suited with develop websites in PHP., etc.
Light Weight - Usually in Web development the space is an important issue,MySQL occupies less memory as compared to others so it is considered to be light weight.
While there is fight between gaints like Oracle vs SQL Server on Enterprise application, the MySql focused on the WEB Development and made popular.
...
I've been dwelling on this topic for a long time now. I just wondered if anyone else out there shared my opinion. Isn't it essentially a bad idea integrating preview versions of programming frameworks into your project code before they are at release candidate level?!
I had a situation a few months ago where my boss insisted on using the Managed Extensibility Framework to handle dependency injection in a huge internal system we were building. We built the code around a preview version of this framework and then Microsoft released another version of it. We updated and everything broke, huge amounts of code had to be re-understood and changed...total pain!
...I'm getting the feeling that Ria Services could present us with a similar problem (or any other framework chosen to be implemented into a projects source code prior to full release state).
Opinions welcome.
Well, what else can be said? You're right - using something not even marked as release candidate for core functionality in your app is a considerable risk.
To alleviate the risk you could try creating a compatibility layer that you could adjust to "translate" to new versions of the framework - but that involves a lot of guesswork that may not work out.
And of course you can just stick with the preview version, if it already does everything you need. But that will bring its own headaches down the road.
All in all, I'd avoid it unless the newfangled thing in question definitely enables you to do something important that would otherwise be impossible, or yields massive productivity gains.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Recently I found out that the company a friend of mine co-owns uses 4D, which I've never heard of before. They swear by it, but they're non-technical and what they say about it sounds like memorized marketing blurb. Unfortunately the 4D website also seems devoid of any actual information and is filled with words like "comprehensive", "solution", "platform" and "integrated" instead.
Since that thing is rather expensive and uses a custom language that I don't have much inclination to learn just for one project, I'm cautious about it and I'm wondering if anyone had any experience with it? Would you recommend it? What is it good for? What competitive advantage would I gain by learning it as a programmer, or using it as a company?
4D has been around for a long time (~25 years), so it's much older than e.g. MySQL. Think of it as a professional version of Microsoft Access: It has its own Pascal-inspired host language, its own relational database engine, a very mature IDE for rapid GUI development and a custom runtime which allows for true "write once, run anywhere" (anywhere being Mac OS (X) and Windows, that is). Nowadays, it also understands SQL, there's a server version and even an integrated web server. It's fairly powerful, so the comparison to Access probably does not do it justice.
Today, I believe it's mostly used for legacy apps which are as old as 4D is. I don't think I would learn it again today, much less start new projects with it, since you can get the same functionality and then some by stacking up open source components.
I used to do some very serious 4D work, one of the systems I wrote is still in use as an enterprise system about 16 years later. I got frustrated because they were taking years to come out with the new object-oriented version of the language and I was writing thousands of lines of code to use a third-party table control.
4D delivers cross-platform, very high-performance client-server systems using a proprietary server. The database model is much more set-oriented than SQL and pulls the sets all the way into the core language. It does a nice job of delivering code to the clients because it compiles all procedures to native code which is cached locally and updated on-demand when it is out of date.
The language and GUI environment have their quirks but the flip-side is that there will probably be a good living to be made from supporting it as a legacy platform. if you can get someone else to pick up the tab for the tools, it may be a useful addition to your consulting toolbox. You have to consider how much business-specific code is gonna be out there for a unique product with that long a history!
An engineer for whom I have huge respect was recently hired by 4D which says a lot about their commitment to the future, hiring this kind of guy.
I've been working a lot with legacy systems recently, doing a port from old Mac stuff to WPF and the contrast between the mostly-unused complexity of Visual Studio and old Mac tools reminded me of 4D. I'm also porting my OOFILE C++ database and reporting frameworks to REALbasic - the OOFILE set-oriented operations came directly from what I loved about 4D and this too made me think I was too harsh in this answer originally.
The thing to remember about 4D is that it was set-oriented from the beginning (written by a mathematician) and much easier to use for many things than SQL. The deployment model of 4D Server is a superb combination of desktop app and network provision - compiled components are cached on the server and automatically sent to a client when needed. There's no need to shutdown or actively push or deploy updates. The GUI model of 4D was frustrating but looking at the site today, they have solved most of the issues that I had to use third party solutions for years ago.
Avoid it like the plague. My company uses it and it's just a constant exercise in frustration. It performs no where near as well as the sales pitch would have you believe, and documentation is either non-existent or not helpful.
In my opinion, there is no reason to begin learning 4D unless you want a simple database app and are unable or unwilling to learn how to create GUIs in a bigger language. The main advantage that 4D has is that the built in functionality between the UI and the database can handle most of what is needed. If you want something quick, small, and inhouse, you can get by with 4D but if you need to develop a powerful commercial application you will run into a few walls. If you need something that 4D doesn't provide automatically it will be very difficult to get it working.
I consider the language completely archaic. It works for what it does but our product has become limited by the language and database itself. We keep running into weird quirks and have to code our way around them.
I have experience in 4D 2003 and 2004 but we haven't upgraded to the latest version because of the costs. It is extremely expensive. Each customer needs to buy licenses for each computer that needs to run the software. Our product costs over $1000 for a new office because of the licenses. When a new version of 4D is released every single customer has to pay to upgrade their licenses.
After looking at https://www.4duk.com/products/ataglance.html, I'd recommend you stay clear - it looks like one of those products that's going nowhere.
It reminds me of the time I was made use a development platform called Witango - absolute nightmare to use, and all apps had to be rewritten in .NET very shortly afterwards.
Invest your time learning something more mainstream/employable.
Avoid at all cost. 4D used to be a good Mac database twenty years ago but is obsolete today. Extremely expensive to deploy and poorly supported. I have used it for many years and have since moved to Real Studio for cross-platform database development, which has a more modern language and a far more active developer community.
I'll be wary of investing too much into something like this. On the good side, if that's what your company uses learning it will pay dividends. But the skills you learn will be hard to use in other places.
I think more than half the replies over here are inaccurate. I know of more than 20 companies with over 1000 users. And I believe there are a lot more.
With 4D v12.1 (www.4d.com) you can easily deploy at the click of a button for single-user, client server, Mac, Win. And there are easy to setup plugins for integration with Flex, iPhone and Android OS. Their KB and documentation is very neat and comprehensive.
They have a great engineering team and the support from 4D and the online community is just fabulous. I have been using 4D for several years and I have no complaints.
4D as someone else pointed out gives you a fully integrated backend database and frontend. The client server connections are stateful so you dont need to worry about record handling and client server session handling.
At less than $1000 per year it is not expensive and you can deploy unlimited single user apps. Which other propreitory development platform gives you that?
I am sure Real Software has its Pros and Cons too. There are many choices nowadays and there are many ways to skin a cat.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
With iPhone and Android I feel Symbian is obsolete. But it is going to be open sourced. However the API looks like very different. With so many different types of discriptors, arrays and Active objects people feel creepy about it. Loo in wikipedia articles here:
http://en.wikipedia.org/wiki/Symbian_OS#Developing_on_Symbian_OS
http://en.wikipedia.org/wiki/Active_objects
I think when it goes open, the first thing community should do is cleaning it up. Though its very difficult but I feel its necessary.
The main reason, symbian is going opensource is to become competitive. The main advantage of Symbian is it is very stable with more than a decade of mobile experience. With the strong support of Nokia, and port of Qt it can definitely a major player.
Wikipedia isn't exactly representative.
Symbian OS development basics have recently been boiled down to under 50 pages in http://www.quickrecipesonsymbianos.com
There is an entire ecosystem that knows about the specifics of developing for Symbian OS. The C++ idioms might be a pain to learn but they have a purpose when it comes to using a mobile platform.
There is little technical justification to get rid of them.
Making things simpler for developers is another goal. A very important one, though. That's why many runtimes have been introduced for Symbian Os development. Qt, Ruby, Java, python, OpenC, Flash, NS Basic, .Net...
The customized, open C++ allows developers to add runtimes efficiently.
Each runtime has its own trade-offs to balance performance and ease of use.
Open sourcing will make runtime integration and native c++ development easier for sure but there also is a commercial point to it too. It gets more people interested and the platform compares more favourably to its competitors.
I think it's too early to say whether Symbian going open-source will be a good or bad thing for the OS. The debate over the branding selected for the Symbian Foundation website shows a certain lack of clarity of the role Symbian software will play in the future.
While it's true to say that there is an entire ecosystem that knows about the specifics of developing for Symbian OS, that's pretty meaningless in its own right. After all, there's still an active "ecosystem" that knows how to develop Cobol applications for IBM mainframes.
You need to consider the size of the ecosystem and appreciate that that ecosystem is small given that Symbian OS has been around for over a decade and the software powers in excess of 100 million devices today. Consider then the rate of growth of the ecosystems surrounding the offerings from Google and Apple - Symbian never generated that level of excitement and never saw that sort of growth in developer interest. Of course, we're a decade down the line and you could argue Symbian have done the hardwork and created the landscape in which Google and Apple are now competing. But just because Symbian was first, doesn't make it best and doesn't give it any right to survive.
It is true to state that the Symbian C++ idioms are a pain to learn. However, it is incorrect to suggest that there is no justification for getting rid of them. The justification is the persistent perception, 10 years on, that developing native code for Symbian OS is too hard. Most if not all these painful idioms were design decisions taken over a decade ago and whilst still beneficial on todays mobile devices are no longer essential. Mobile hardware has moved on substantially in the last decade. Symbian OS has not fundamentally changed, at least in terms of the developer offering. Consider now where PCs would be if the hardware had developed as it has, but the software stopped at Windows 3.1 or 95. We almost certainly wouldn't be able to have this discussion in quite this way for starters.
Looking at alternative mobile platforms, consider Android and Maemo. Both are linux based systems. Both use more developer focussed, standard development approaches which leave Symbian OS looking like it's come from another age.
That in itself is not necessarily a problem because as others have noted, Symbian OS supports several runtime environments that make development for mobile devices that happen to run Symbian OS much more approachable for the average developer.
Taking the runtime support to its natural conclusion, the underlying OS becomes irrelevant. A choice made by the device manufacturer based on cost, time to market, quality etc. But the end user doesn't care and in many cases doesn't know what the OS is. Developers then develop for their preferred runtime, rather than write native code.
Of course, we're not at that conclusion yet. We're still travelling the long road. Therefore native code still plays an important part in mobile devices. Hence the ease with which developers can write for a given platform is important - assuming the device manufacturers believe in supporting developer platforms.
So, will open sourcing be good for Symbian? It's difficult to see how open sourcing will be bad for Symbian. But whether it will be good or not depends on the ability of the community to make Symbian OS into the OS the community needs.
there's a move in symbian os towards using more common languages for development, including C, ruby python etc. try thinking of symbian c++ as like WIN32 programming (you're not telling me that's easy!), if you don't want to use it you don't have to but it's the native language and therefore most efficient.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
In evaluating different systems integration strategies, I've come across some words of encouragement, but also some words of frustration over BizTalk Server.
What are some pros and cons to using BizTalk Server (both from a developer standpoint and a business user), and should companies also consider open source alternatives? What viable alternatives are out there?
EDIT: Jitterbit seems like an interesting choice. Open Source and seems to be nicely engineered. Anyone on here have any experience working with it?
BizTalk Server's key benefit is that it provides a lot of 'plumbing' around deployment, management, performance, and scalability. Through Visual Studio, it also provides a comprehensive framework for developing solutions, often with relatively little code.
The frustration and steep learning curve that others mention often comes from using BizTalk for the wrong purpose and from a misunderstanding about how to work with BizTalk and message-oriented systems in general. The learning curve is not as steep as most people suggest - the essential part of the underlying learning actually focuses on changing thinking from a procedural approach to a stateless message-based approach.
A drawback people often cite is cost. The sticker price can seem to be quite high; however, this is cheap in comparison to the amount you'd spend on developing and supporting features on your own.
Before you consider alternatives, or even consider BizTalk server, you should consider your organization's approach to integration and it's long term goals. BizTalk Server is great in cases where you want to integrate systems using a hub and spoke model where BizTalk orchestrates the activities of many applications.
There are other integration models too - one of the more popular ones is a distributed bus (don't confuse this with the term "Enterprise Service Bus" or ESB). You can also get BizTalk to work as a distributed bus and there are alternative solutions that provide more direct support. One of the alternate solutions is an open source solution called nServiceBus.
When considering whether to use a commercial product like BizTalk, verses something else (open source or developed in house), also consider maintenance and enhancements and the availability of the necessary skill-set in the marketplace.
I wrote some articles that go into more detail about the points I discussed here - here are the links:
Why BizTalk?
Top 10 BizTalk Mistakes
Extensibility Features in BizTalk Server
Open Source Integration with nServiceBus
My experience with BizTalk was basically a frustrating waste of time.
There are so many edge cases and weird little business logic tweaks you have to make when you are doing B2B data integration (which is probably the hardest part of any enterprise application) that you just need to roll your own solution.
How hard is it to parse data files and convert them to a different format? Not that hard. Unless you're trying to inject a bloated middleware system like Biztalk into the middle of it.
As a BizTalk consultant I have to agree at least partly with Eric Z Beard, there are a lot of edge cases that take up alot of time. But quite a few scenarios are handled extremly smooth as well, so it all depends IMO. But when you (Eric) call BizTalk bloated I have to disagree! We've found that the performance and reliability is excellent, it's flexible and comes with a lot of good adapters out of the box.
BizTalk needs to be used correctly,
I am a BizTalk developer and my experience with BizTalk is quite good.
Its reliable, performant, scalable, contains a lot of built in architectural patterns and build in components to make integration easy and fast, you get security, retries, secondary transports, validation, transformation etc... and what ever you dont have build in with BizTalk you can easily customized with .NET code, its basically a hard earned integration system and you get all this in one box.
BUT you need to know how to implement BizTalk correctly, not once I came across solutions that where implemented and often also architected incorrectly.
but the real benefit of BizTalk is that you can implement small solutions and scale up whilst most other integration systems from big vendors will only sell a whole integration pack which can cost much more.
BizTalk is considered the most complicated server from the house of Microsoft.
So any body saying BizTalk is not good dosent know BizTalk period.
We evaluated BizTalk at our company and were really disappointed.
We are using IBM WebSphere Transformation Extender (which has lots of (other) problems, too) and the mapping tool of BizTalk is a joke in comparison to WTX.
The graphical tool is not really usable for complex mappings (we have schemas with a few hundred fields in repeating groups) and if you do more than the usual "concat first name and last name to name" mappings, you will be tired of the graphical approach (for example the arguments of the functoids in the graphical mapper are not labeled and the order in which you connect fields to these arguments is important).
The XSLT-Mapper was usable but not really convincing, and even the microsoft rep told us to use a tool like XMLSpy for XSLT and load the resulting XSL file into BizTalk.
A third approach to mapping is to use C#-Code for the mapping, which was not acceptable for us as a general approach (we don't want to teach everyone C#).
In addition to the mapping tool we did not like the deployment in BizTalk. In order to deploy your process, you need to make lots of settings in different tools and places. We had hoped to find a mechanism like a WAR file for Java Web Applications in BizTalk, so that you can give one archive for your whole process solution to your administrator and he can deploy it.
We've been using BizTalk since version 2004, and now have a mix of versions 2006 R2 and 2004 running. I found that the learning curve was quite severe, and development time for solutions is not always quick. Those are definitely shortcomings. Where BizTalk really excels is in its fault tolerance, gauranteed delivery, and performance. You can rest assured that data will not get lost. Retry functionality and fault tolerance robustness is baked in so generally speaking if systems are down BizTalk will handle that and successful delivery will occur once systems come back on line. All these issues such as downtime, etc that are important in an integration scenario are handled by BizTalk.
Further, generally speaking when developing solutions BizTalk abstracts the communication protocols and data formats of the native systems by dealing with everything as xml, so when developing solutions, you typically don't have to wrote code specific to those systems, you use the BizTalk xml framework.
In the last year, we've implemented a java open source engine called Mirth for our HL7 routing. I found that for HL7 purposes, the HL7 adaptor for BizTalk is a challange to work with. Management dicated that we use Mirth for HL7 routing. Where BizTalk falls down in terms of learning curve, Mirth makes up. It is far easier to develop a solution. The problem with mirth is that it doesn't really have any gauranteed delivery. Most of the adaptors (except for hl7) have no retry functionality so if you wanted that you'd have to write your own. Second, Mirth can lose date if it goes down. I would call it very easy to use (although there is no documentation) but I'd be hard pressed to call it an enterprise solution. I'm going to check out jitterbit which was mentioned by someone else.
We used BizTalk for a couple of years, but gave it up for our own custom framework that allowed more flexibility.
There is always Sun's (now Oracle) OpenESB framework. Its generally speaking a smaller, lighter version of Biztalk but with roughly all the same features.
You do get to write more code with it, though.
Its Open Source as well.
In the OSS space (though I've never used them as a BizTalk replacement personally - this is anecdotal) you can use one of the Java/J2EE Messaging engines such as OpenMQ (which is the Sun enterprise one rebadged and without support). If you need Orchestration / Choreography (i.e. SOA/ESB pieces) on top of this, you could look into something like Apache Mule
My experience with BizTalk and doing B2B integrations is that most organizations do not truly do schema first design or fully understand xml standards for that matter. Most tend to weave objects and hope they materialize into meaninful schemas. In an enterprise environment, this is backwards.
BizTalk does have a learning curve, but once you get it you are rewarded with durability, performance, true scalability, and extensibility. Like most have said though, it best to make sure it meets your needs and contort your needs to BizTalk.
In the past I have worked with BizTalk 2004 through 2009, and another product called webMethods.
I have no direct experience with JitterBit, but I have heard very good things from coworkers.
I came across Apatar (unable to post url, but Google finds it) while looking for a solution cheaper than BizTalk. I have yet to try this out.
My last company had many problems with BizTalk being too complex and ridged, but I can’t help but think this was mainly down to the implementation the consultant did.