At my current job, it goes without question that if a new version of a technology that we use in our project is released, we upgrade it ASAP. At my previous job, that was not the case... we had to convince management that it was necessary. As such, we often had to do without features that could have been helpful and continue living with bugs that had long ago been fixed. At times, it was even hard to get support for the old versions we were using. I don't really see that point of view, especially after experiencing the opposite approach. Are there really 2 sides to this question?
Of the two approaches, I absolutely would prefer the one where you are now. Having applications falling behind can be painful for many reasons, some of which you noted.
The only caveats would be centered around time, really; it would usually take some non-trivial amount of time to update something for new frameworks/dependencies. It's nice when frameworks maintain backward-compatibility, but that does not always happen.
Breaking changes are usually obvious, and usually (we hope) exist for some very good reasons. More troublesome are the silent changes that do not prevent building, but cause subtle bugs; like a library function with the same signature, but which has slightly different behavior or return results.
But if an application is meant to be supported long-term, keeping it up-to-date is really a must, IMO.
There is a grey area that lies somewhere in the middle.
Your old place lived by a "don't rock the boat" approach. Yes the stuff might not be up to date but they knew what it could do (and maybe couldn't) and how to handle it. If theres an issue you hopefully know its not the kit as its been around the block (or you've been around the block find out all the bugs in it and how to handle them and keep your kit up and running).
Your new place puts all their faith in the fact that the newer kit must be better and can't possibly have been released without lots of checks and balances. Yes there might be some quirks but knowing some of those old bugs are no more (well the release docs say its fixed anyway) is worth the time spend finding new bugs in the latest release.
Its a fine line to tread and depends very much on what the tech is used for and how mission critical it is.
Yes, there certainly are two sides to this question. I'll weigh in on the side of not upgrading whenever a new version is released ...
If it ain't broke don't fix it. If your system is working then any
change is a risk, not all risks are
worth taking.
If you upgrade every time a new
release of any component pops up you
will find yourselves following other
people's schedules.
Change management is vital discipline for robust and reliable systems.
Related
Everyone likes to talk about reusability. Where I work, whenever some new idea is being tossed around or tested out, the question of reusability always comes up. "We want to maximize our investment in this, let's make it reusable." "Reusability will bring higher quality with less work." And so on and so on.
What I've found is that when a reusable component or idea is introduced, everyone is immediately afraid of it and writes it off as a bad idea. Once applications become dependent on it, they say, it won't be maintainable, and any changes will result in the need to do regression testing on everything that uses it. People here point to one component in particular that has been around a long time and has a whole lot of dependents and grouse that it's become impossible to change becuase we don't know what the changes will break.
My responses to this complaint are:
It's good that change to a component
that has many dependents is slow,
because it forces the designers to
really think through the changes.
Time should be taken to get the
component right in the first place. Corrollary: If you're finding the need to change it all the time, it was never very reusable to begin with, was it?
Software development is hard and requires work. So does testing. You just gotta do it.
Unfortunately, what people hear in these responses are "slow," "time" and "effort."
I would love if there was a magic "make this reusable" switch I could flip on things I build so as to win brownie points from management, but things don't work that way. Making something reusable takes time and effort and you're still not guaranteed to get it right.
How do you deal with the request for "reusability" when delivering on it seems to bring nothing but complaints?
Reusability is only worthwhile if something will actually be reused. Make sure you have some practical reuse cases before you write something reusable.
Even if a reusable library is 10x harder to maintain than an ad-hoc version of itself, you're still saving on maintenance overall if the reusable library is used in place of ad-hoc versions in 10 different places.
Reusability is to make code reusable in term of similar behavior or "IS_A" relationship. If you just want to reuse code block by seeing them using again and again but they have no similar characteristic, you should better leave them alone to be loosely coupling. By that, we can have more flexibility to modify later.
One thing that we often do is to use versions and avoid the constant retesting. Just because there is a new version of common code doesn't mean everything has to use the new version right away. When something is getting updated for other reasons, update to the new version of the common code.
We are a team working on legacy code which is pretty old and written in languages of initial programming days. As the team members are trained in latest technology and are now put to work on legacy code, they are not happy. How to motivate them to work in legacy code also?
Send your team to meet users and watch them use software. They should find out what are most critical problems users have with that software.
Getting to know users makes work more real - your team will know that adding new functionality or eliminating some bugs will help some real person. That should motivate programmers to get boring job done.
Only cash can not make the developers happy. You should provide them good environment so that they can pay attention to their work.
Another thing is no technology is bad OR legacy OR older. Thing is if your company needs to maintain it, then you must keep it going. But keep all standards for designing, coding, testing, code review, interactive sessions etc..
Also you can motivate them to convert your legacy code to some new platform for better performance and maintainability. Every company does that even once i think, because they want to compete with other market products.
Also provide them some cool sessions for other technologies which are used in your company but they don't know or use. Let them be deeply in the things, give them proper time and support for problem solving. Main goal is to deliver on time with less rework and bugs.
Provide some rewards towards their work and keep them happy about their work.
thanks.
i really like "Send your team to meet users and watch them using software"
If i have to motivate my team, I will really ask my developer to visit the use and find out how much user is happy with the product.
I will really like to take challenge on how we can make it more better then what exist.
Do you have some scope for retiring the legacy code in the foreseeable future? If so, "we only need to keep this going until..." might sweeten the pill.
Are the team members experienced in the languages/environments which the legacy code is written in? If not, it might be simple reluctance to do something that they don't know how to operate. Possibly scheduling in some time for them to gain at least a passing familiarity might be in order; provided it's not too much of a paradigm shift from latest technology, it shouldn't be all that hard?
Are the team members only allowed to work on the legacy code team or can their time be split between different projects? I don't think anyone is going to be happy about spending a 40 hour week on FORTRAN debugging. But if you have to spend a few hours on the legacy code knowing that you can take breaks during the day to work on something you actually enjoy it's a little less painful.
And I'll reiterate what was said before about making sure the team members have time to learn and gain experience with the old technologies before throwing them in there. Try to make the training enjoyable too. Our legacy code training was set up as a competition to see who could come up with the fastest/shortest/most complete/etc solution to interesting problems rather than having to look exclusively at the code we were to be working on. Really, that could be applied to the team's plan even if you don't have time set aside for training. Add a little competition to the task at hand or allow a little bit of time for challenging and competitive side projects.
How are they getting rewarded for working on these legacy products? Do you know what motivates them? Some people may prefer timely recognition and praise while others may expect cash or understanding that this isn't necessarily what they signed up for when they initially took the job. I'd be tempted to suggest having 1:1 meetings to see what would they like that would make them happier. Is it more money? More flexibility in time off? Training in the legacy technologies? Affirmation that they are doing good work on these ancient systems, as the initial programming days makes me think of mainframes and other really old tools that one may wonder, "How much longer will this run really?"
Cash isn't the answer. Free food, soft drinks, whatever, that only goes so far at alleviating the drudgery of legacy code work. What about trying to change their perspective?
"Anyone can do good work with modern code that has a nice IDE with refactoring built in, a ton of resources just one Google search away, but we proud few, we band of brothers, we are good enough to do this with ancient procedural languages. We'll tame this awful mess of code and do it with one hand behind our backs and create processes and tools to make sure the next poor bastards won't have it so bad."
I would say the simplest way to attract the most positive emotion from developers to legacy coding would be to make the old new in some way.
Have a session or two to identify what it is that the legacy code does, and then get an idea of what it would take to do it anew on a new architecture. The "new architecture" part is key, because 9/10 times, it's the architecture that is dreaded (spaghetti code, pre-standard conventions, etc...).
If you can't get your re-write estimates approved, then at least work out a plan to get your refactoring of legacy code into the daily maintenance. At the very least your developers will feel as though they are working towards something, and something new at that, instead of just monkey-wrenching the old decay that no one wants to even remember.
Just my 2ยข.
You can for example try to do fancy things on the testing side. Try out mocking frameworks etc.
Try also emphasize that handling legacy code is a good experience if you want to become a solid programmer, since every technology becomes eventually legacy.
Extra cash? :) Don't know anything else...
Even if it's new technologies legacy code it's not always a pleasure to work on such code, so on "initial technologies"... i guess the only motivating thing is to discover how programming was these days...
The amount of Time required in spending motivating the team and learning the legacy code and fixing it half heartedly can easily be used to build the same stuff in new platform , given the amount of resources , IDEs , expertise , frameworks etc available for free, the Good news you have the system in place you just need to meet the same behavior in new platform unlike we have to build something new for some product whose behavior and user experience we dont know .
I'm planning on starting a new project, and am evaluating various web frameworks. There is one that I'm seriously considering, but I worry about its lasting power.
When choosing a web framework, what should I look for when deciding what to go with?
Here's what I have noticed with the framework I'm looking at:
Small community. There are only a few messages on the users list each day
No news on the "news" page since the previous release, over 6 months ago
No svn commits in the last 30 days
Good documentation, but wiki not updated since previous release
Most recent release still not in a maven repository
It is not the officially sanctioned Java EE framework, but I've seen several people mention it as a good solution in answers to various questions on Stack Overflow.
I'm not going to say which framework I'm looking at, because I don't want this to get into a framework war. I want to know what other aspects of the project I should look at in my evaluation of risk. This should apply to other areas besides just Java EE web, like ORM, etc.
I'll say that so-called "dead" projects are not that great a danger as long as the project itself is solid and you like it. The thing is that if the library or framework already does everything you can think you want, then it's not such a big deal. If you get a stable project up and running then you should be done thinking about the framework (done!) and focus only on your webapp. You shouldn't be required to update the framework itself with the latest release every month.
Personally, I think the most important point is that you find one that is intuitive to your project. What makes the most sense? MVC? Should each element in the URL be a separate object? How would interactivity (AJAX) work? It makes no sense to pick something just because it's an "industry standard" or because it's used by a lot of big-name sites. Maybe they chose it for needs entirely different from yours. Read the tutorials for each framework and be critical. If it doesn't gel with your way of thinking, or you have seen it done more elegantly, then move on. What you are considering here is the design and good design is tantamount for staying flexible and scalable. There's hundreds of web frameworks out there, old and new, in every language. You're bound to find half a dozen that works just the way you want to think in your project.
Points I consider mandatory:
Extensible through plug-ins: check if there's already plug-ins for various middleware tasks such as memcache, gzip, OpenID, AJAX goodness, etc.
Simplicity and modularity: the more complex, the steeper the learning curve and the less you can trust its stability; the more "locked" to specific technologies, the higher the chances that you'll end up with a chain around your ankle.
Database agnostic: can you use sqlite3 for development and then switch to your production DB by changing a single line of code or configuration?
Platform agnostic: can you run it on Apache, lighttpd, etc.? Could you port it to run in a cloud?
Template agnostic: can you switch out the template system? Let's say you hire dedicated designers and they really want to go with something else.
Documentation: I am not that strict if it's open-source, but there would need to be enough official documentation to enable me to fully understand how to write my own plug-ins, for example. Also look to see if there's source code of working sites using the same framework.
License and source code: do you have access to the source code and are you allowed to modify it? Consider if you can use it commercially! (Even if you have no current plans to do that currently.)
All in all: flexibility. If I am satisfied with all four points, I'm pretty much done. Notice how I didn't have anything about "deadness" in there? If the core design is good and there's easily installable plug-ins for doing every web-dev 3.0-beta buzzword thing you want to do, then I don't care if the last SVN commit was in 2006.
Here are the things I look for in a framework before I decide to use it for a production environment project:
Plenty of well laid out and written documentation. Bad documentation just means I'm wasting time trying to find how everything works. This is OK if I am playing around with some cool new micro framework or something else, but not when it's for a client.
A decently sized community so that you can ask questions, etc. A fun and active IRC channel is a big plus.
Constant iteration of the product. Are bugs being closed or opened on a daily/weekly basis? Probably a good sign.
I can go through the code of the framework and understand what's going on. Good framework code means that the projects longterm life has a better chance of success.
I enjoy working with it. If I play with it for a few hours and it's the worst time of my life, I sure as hell won't be using it for a client.
I can go on, but those are some primary ones off the top of my head.
Besides looking at the framework, you also need to consider a lot of things about yourself (and any other team members) when evaluating the risks:
If the framework is a new, immature, "bleeding-edge" framework, are you going to be willing and able to debug it and fix or work around whatever problems you encounter?
If there is a small community, you'll have to do a lot of this debugging and diagnosis yourself. Will you have time to do that and still meet whatever deadlines you may have?
Have you looked at the framework yourself to determine how good it is, or are you willing to rely on what others say about it? Why do you trust their judgment?
Why do you want to use this rather than the "officially sanctioned Java EE framework"? Is it a pragmatic reason, or just a desire to try something new?
If problems with the framework cause you to miss deadlines or deliver a poor product, how will you talk about it with your boss or customer?
All the signs you've cited could be bad news for your framework choice.
Another thing that I look for are books available at Amazon and such. If there's good documentation available, it means that authors believe it has traction and you'll be able to find users that know it.
The only saving grace I can think of is relative maturity. If the framework or open source component is mature, there's a chance that it does the job as written and doesn't require further extension.
There should still be a bug tracker with some evidence of activity, because no software is without bugs (except for mine). But it need not be a gusher of requests in that case.
By using somebody else's works you advertize the authors of those works (At least, among other programmers). Do you think it is cool?
This line of questioning could go up one more level and become "Programming Languages: Do you think it's cool to use those?" Because someone(s) wrote those too. I can continue this up to the types of computers, to the components, etc...
Monet did not make the brushes or the paint or the canvas (well maybe, not sure). But who creates those building blocks is not quite what stands out at the end.
Languages/Frameworks/etc were built and released to be utilized by the masses (or make money for the creators).
I think it's always cool. Be more efficient, reduce redundancy, promote other useful code.
If you're trying to learn though, reading and understanding the framework you're using is very helpful. There are always other things you can be programming and learning, not necessarily reinventing the wheel.
If using their work has saved you time reimplementing the same thing (but with more bugs) then don't they deserve credit?
Or put another way, stealing other peoples' work without credit (or paying them, depending on whether we're talking about free or commercial software here) isn't cool.
Of course, nobody's stopping you from writing your own framework, if that's what you want to do...
It depends on what kind of programming you're doing.
Are you doing it to achieve a finished program? Then a framework could save you a lot of time.
Are you doing it to create something truly original? Then a framework might simply tie you into an existing way of thinking.
Rembrandt made his own paints. Michelangelo selected his own marble from the quarry. Alan Kay said "People who are really serious about software should make their own hardware". The Excel team famously has their own compiler. The iPhone ain't just an alternate firmware for the Blackberry. ISTM if you want to be at the very top of your game, you've got to get down and dirty with the nitty gritty of it.
I don't know anything about advertising, other programmers, or what's "cool", so I can't respond to those parts of your question.
I work with a lot of open source libraries in my daily tasks (java FYI). By the time a project comes close to maturing, many of the libraries have released newer versions. Do people generally upgrade just to upgrade, or wait until you see a specific bug? Often the release notes say things like "improved performance and memory management", so I'm not sure if it's worth it to potentially break something. But on the other hand most libraries strive and claim to not break anything when releasing new versions.
What is your stance on this? I'll admit, I am kind of addicted to upgrading the libraries. Often times it really does help with performance and making things easier.
The rule for us is to stay up to date before integration testing but to permit no changes to any library once we're past this point. Of course, if integration testing reveals flaws that are due to an issue with a library that has been fixed, then we'd go back and update. Fortunately, I cannot remember a situation where that has happened.
Update: I understand Philuminati's point about not upgrading until you have a reason. However, I think of it this way: I continuously pursue improvements in my own code and I use libraries built by people that I believe think the same way. Would I fail to use my own improved code? Well, no. So why would I fail to use the code that others have improved?
I keep what works until there is a reason to upgrade.
If the information pertaining the old version appears on secunia or securityfocus...
Otherwise - if new functionality is needed (better performance is also a 'functionality').
I'm with the lazy crowd - I can't remember ever formulating a different strategy than "upgrade when there is a reason to" - but now that I consider the question, there is something to be said about proactive upgrades.
Upgrading does make it easier for you to report a bug in the lib, should you find one. If you find a bug and have not upgraded, it's the first thing you're going to have to do before you get any help or support. You might as well do that proactively.
Especially if you have a good test suite, upgrading proactively will flush out problems early, and that is always a smart move.
It depends a lot on your deployments. If you are supporting multiple platforms then the very latest libraries may not be available on all at any given moment. I've been frustrated by trying to install something that requires the very latest version of some lib, and it's not available as a package yet.
If you deploy to customers you want to develop against libraries that are stable and widely available.