Last week Sun launched JavaFX, its Java-based platform for Rich Internet Applications. Sun picked up the high level of interest in Adobe's Flash as an application runtime, and perhaps Microsoft's Silverlight as well, and hurriedly developed its own equivalent. JavaFX is a new scripting language that runs on the JVM (Java Virtual Machine) and is optimized for graphical effects and multimedia. It brings to Java animation features like timelines and motion paths, support for a variety of audio and video codecs, and a way of coding a graphical user interface without the supposed complexities of Swing with its Model/View/Controller (MVC) design. JavaFX applets can run within or outside the browser. One innovation is that you can drag an applet out of a web page and onto your desktop. If you close the browser, the applet keeps running, thanks to support for out-of-process plugins in Internet Explorer 7 and Firefox.

So far JavaFX has received a mixed reception, and it is easy to see why. The launch was rushed, and some early visitors to the site had a bad experience, with videos that would not play or samples that did not run. Videos running in JavaFX flash unpleasantly if you resize the browser. The install experience is not as smooth as for Flash or Silverlight in my experience, because you need to install the Java Runtime Environment (JRE) as well as the JavaFX plugin. The download size is larger, although this is disguised by Sun's slimmed-down initial install. The idea is that you get up and running quickly, while the rest of the JRE installs in the background. The SDK does not yet run on Linux or Solaris, although the applets themselves should run because they only require the standard JRE plus a runtime jar (add-on library) and can be executed using Java Web Start. The latest NetBeans has JavaFX support, but another downer is the lack of any dedicated visual design tools. Sun only offers an export add-on for Adobe's Photoshop and Illustrator, or a converter for SVG (Scalable Vector Graphics). There is no 3D API yet, though it is promised.

It is easy to be negative; but some of these problems will disappear as JavaFX matures. A visual design tool is in the works, as is a mobile version that will be shown at the Mobile World conference in February next year. JavaFX will have a place for Java developers who are envious of what Flash and Silverlight can do. While it may not match Flash in terms of broad runtime deployment, I'm guessing that Sun will outpace Microsoft in this respect. JavaFX also has a couple of advantages over Flash, including more sophisticated client-side security and better code performance in some scenarios. The Java VM is mature and well optimized. Adobe's ActionScript virtual machine does have a just-in-time compiler, but seems slower than either Silverlight or Java for code execution. Speed of graphical effects is another matter, and while I have not seen any comparisons yet, I suspect Adobe's long multimedia experience may come into play here.

JavaFX will be welcomed then by Java developers who need more expressive graphics in their applications, and will be an interesting option for those developing games for mobile devices. Try as I might though, I'm finding it hard to believe that this is a huge section of the market, or that Sun will have much success persuading designers to target JavaFX rather than Flash, or that JavaFX will win much market share from Adobe for web-hosted video. Swing works well these days, its MVC architecture has merit, and it is well-suited to the kinds of Enterprise applications which commonly have Java clients. JavaFX is a useful addition to Java, but I doubt that Adobe is losing sleep over its likely impact. That said, I'm keen to hear from developers with plans for JavaFX applications, so don't hesitate to let me know.

Adobe's MAX conference in San Francisco this week was focused on what it calls the "Flash Platform", a technology stack oriented round the Flash multimedia runtime. The "platform" word highlights the fact that you can code for Flash and have your application run everywhere that Flash runs, including Windows, Mac, Linux, and some mobile devices as long as they are not from Apple. It is not a complete platform, being essentially an Internet client, though there are some server-side pieces such as LiveCycle Data Services, to simplify and optimize communication between Flash clients and Java middleware. You can also blur the distinction between browser and desktop with AIR, which runs Flash outside the browser and adds a local database engine.

So what's new? There was the usual set of announcements. The key ones are as follows:

AIR 1.5: an update to the desktop runtime which adds support for Flash Player 10 features such as Pixel Bender, for runtime graphical effects, and an option to encrypt local databases. There is also the SquirrelFish JavaScript interpreter - though this only comes into play if you are running JavaScript within HTML, rendered by WebKit, rather than ActionScript without the Flash runtime, which has its own just-in-time compiler. AIR 1.5 is available now.

A new version of Flex and the Eclipse-based Flex Builder IDE, code-named Gumbo. This has a new skinning and component architecture, more advanced text rendering, easier two-way data binding and a new Client Data Management (CDM) feature which from early descriptions looks reminiscent of a .NET dataset. You work with data on the client, storing updates locally, then zap the updates back across the wire in a single update operation. One thing that is not yet clear to me is the extent to which CDM requires LiveCycle on the server; I'll be sure to clarify this in a couple of weeks at MAX Europe (I was not present at the US event). The database aspect is significant, because so many enterprise applications boil down to CRUD (Create, Retrieve, Update, Delete) in one form or another.

Catalyst, formerly code-named Thermo, was previewed. This is a fascinating product which converts Photoshop artwork into Flex code; it also allows designers to create and preview a degree of interaction in their designs. Catalyst shares the same project format as Flex Builder. Again, I will be taking a closer look at MAX Europe. Here's a preview screen grab:

 

Cocomo (yet another codename) is a cloud effort from Adobe, focused on conferencing. Adobe hosts the services and provides Flex components to enable file sharing, text and VOIP (Voice over IP) chat, whiteboards, and data messaging; there is also user management built in.

Alchemy is a tool that converts C/C++ code to ActionScript, for execution within the Flash player. It's intended for re-use of existing libraries, not for general development.

Third-party announcements that caught my eye included Ensemble's Flex add-in for Visual Studio (though I was underwhelmed by the preview), and Zend's addition of AMF (Action Message Format) into its PHP Framework. AMF is a binary format that optimizes data transfer between servers and Flash clients.

Although none of these announcements is spectacular in itself, taken together they show the momentum behind Flash as a client for applications as well as video and multimedia, as I have mentioned here before. A good thing? Designers love Flash because of the freedom it gives them, along with the excellence of Adobe's design tools - Creative Suite 4 really is spectacular. Nevertheless, I have a nagging concern that if we adopt Flash rather than AJAX - interactivity in HTML and Javascript - for our next-generation clients, we are giving away the openness of the Web, because Flash is proprietary technology. I recommend this thoughtful post from Google's Brad Neuberg, which recommends not only open-sourcing the Flash runtime, but also integrating it more deeply with the browser and embracing web standards. There's little chance of Adobe adopting Neuberg's proposals, but he does a good job of spelling out the issues. Flash is compelling, as is Microsoft's Silverlight, but each is controlled by a single vendor. Do you think that matters? I'd be interested to hear your opinions.

 

I'm at Microsoft's Professional Developer's Conference (PDC) in Los Angeles, where we've heard a ton of stuff about Microsoft's forthcoming technology. A lot of the press has focused on Windows 7, and that's understandable since Windows is what many of us stare all day. I've been running Windows 7 myself since Sunday, in an pre-beta build, and I'm both impressed and unimpressed.

The good bit: Windows 7 is better than Vista in every way I can think of. Even in the pre-beta, it is fast and stable. Even better, Microsoft has worked on making Windows "quieter" - reducing the number of distracting dialogs and notifications, and giving users more control over them.

Too much "toast" popping up in the system tray? Just choose "Customize", and you can turn off notifications from applets that are annoying. Too many prompts from Vista's User Account Control, the thing that flashes the screen and asks, "Did you really want to do that"? Now there's a simple slider that lets you minimize the prompts. Provided that you avoid the lowest level, security is not much compromised.

There are other user interface changes, but the nagging question is whether Windows 7 really merits a full new version number. In fact, Microsoft says there are no core architectural changes, which is great for driver and application compatibility, but reinforces the impression that this is just Vista done right.

The biggest innovation (if you have never seen an iPhone) is the multi-touch control, which lets you use your fingers instead of the mouse. You can scroll windows with a flick of the wrist, and pinch the screen to zoom or rotate what you see. Impressive; but whereas this works well on the iPhone which is designed from scratch with this in mind, there are a couple of problems applying it to Windows. First, most of use don't have touch screens, and while that might change, it's also possible that the technology will go the same way as the current Tablet PC, into a small niche. Second, how many application developers will make the effort to support touch properly? Watch this space; but I guess it is possible that mouse and keyboard will remain by far the most common way to control Windows.

The more interesting themes at PDC are outside Windows itself. There's cloud computing, there's Visual Studio 2010, there's news on the future of C#, which as its architect Anders Hejlsberg pointed out, is now a decade old, and plenty more. I'll post separately on some of these topics.

Nevertheless, Windows 7 will be a welcome upgrade when it comes. Which is when? Microsoft won't tell, but I'm guessing we may have it in our hands by this time next year, probably earlier. OEM vendors will want it for the Autumn. To hit that date, Microsoft will need to be complete the OS by the summer. Given the lack of major changes under the hood, that strikes me as plausible.

It's hard not to love PHP: fast, powerful, and useful for anything from quick web scripts to major applications. The trouble is, PHP is just too forgiving for my taste. I've been working with PHP recently and occasionally made some silly errors (my excuse: it was late). I mostly work in other languages, so from time to time I would forget that in PHP variables all begin with a $ character. In other words, I wrote code like this:

$err = 0;
 if (err)

 {

     print("<b>No match with this username and password. Please try again.</b>");

 }

Unfortunately for me, the code ran fine. PHP sees err as an undefined constant which it assumes has a string value of 'err', so the if condition passes. For those used to strongly-typed languages such as C,Java or C#, this kind of error is unexpected, as in those languages the equivalent code will not even compile. Silent errors are particularly dangerous, since they are more likely to make it into production code with possibly calamitous consequences.

I guess the solution is not to make errors like that; but if you are like me, anything the tools can do to help catch errors is welcome. One possibility is to change the error_reporting value in php.ini. If you set it to a strict setting like this:

error_reporting  =  E_ALL | E_STRICT

then PHP will report likely problems in a manner that even a tired programmer will notice:

Check out the comments in php.ini for a description of the options. You would likely only use a strict setting like this in your development environment, not in production.

A snag with this approach is that many PHP libraries out there do not expect such a strict setting and will throw up all sorts of warnings. It wasn't a problem for me, as on this occasion all the code was mine.

As an aside, I've enjoyed working with PHP. I used to find that it almost encouraged spaghetti code, but the object-orientation introduced in PHP 5.0 has made it easier to structure applications in a way that I like. I've also started using the PHP Development Tools (PDT) in Eclipse. If you use this together with an instant PHP environment such as XAMPP, it is easy to set up a desktop for PHP development with luxuries like syntax highlighting, code-completion, and step-through debugging. Taking all these things together, I've found that most of my objections to using PHP no longer apply.

The most striking talk in last week's Future of Web Apps conference in London (FOWA) was from Sun's Director of Web Technologies Tim Bray, well-known as a co-inventor of XML. On a day when the world's stock markets were in sharp decline, he tore up his talk and spoke instead on how developers can survive the coming recession.

His recipe for survival is as follows:

• Go Agile. The Agile development methodology is flexible, delivers high-priority features quickly, and doesn't lock companies into long projects that only yield returns at the end.
• Use open source:

"It's got to be very cheap to deploy technology. In practical terms, that means open source software. I do not see much of a future for Enterprise software."

said Bray. I believe he overstates the case. Companies are not going to make major platform shifts because money is tight; they are more likely to play safe and stick with what they use now. Nevertheless, if you can choose between free and expensive, free is pretty attractive.

• Go to the cloud:

"The business benefits of going into the cloud, you only have to pay a little at the beginning, you don't pay anything serious until you see benefits, are going to look overwhelming."

The snag here is that like the rest of us, Bray hasn't figured out which cloud to go to, and is particularly wary of lock-in. Still, utility computing has obvious cost-cutting potential.

• Lose your programming prejudices. "Stop believing in programming religions," said Bray. I reckon this is his most important point, and relates directly to the others he made. In a downturn it pays to be pragmatic. Developers willing to get out of their comfort zone and try something different for the benefit of their customers will have more opportunities as firms cut back.

What if things get really bleak and a lot of us have time on our hands? Well, at least it is an opportunity for Java developers to learn PHP, or vice versa. Further, as Bray observed at FOWA, getting stuck into an open source project is a great way both to learn new skills and also to build your professional reputation. Never mind the CV; the first thing he does when evaluating a job application is a Google search.

Nobody knows how severe the downturn will be; Bray thinks it will be grim but admits he could be wrong. What is certain though is that the world will still need software development skills, and that the Internet will continue increasing in importance. If this is where your skills lie, that has to be a mitigating factor.

 

You can see highlights from Bray's talk here; and summarized on his blog.

The recent Linux plumbers conference included a session on getting Linux to boot in 5 seconds (see also the write-up here). It was great to see the report, because performance gets far too little attention. Most of the business world runs Windows rather than Linux, at least on the desktop, and in most respects Windows seems slower than Linux on the same hardware. I would give anything to have Vista boot in 5 seconds on my laptop. In fact, the main problem with Windows Vista is not driver compatibility, or annoying security prompts; it's that little spinning bagel that appears only too often. When I start Microsoft Outlook 2007, I brace myself for an extended pause while it starts up, during which the whole system becomes unresponsive. By contrast, I still enjoy using an ancient version of Paint Shop Pro for working with images, even though I have Adobe PhotoShop installed, because it starts in a blink and does exactly what I need.

The old joke is that what Intel giveth, Microsoft taketh away; but it is not a joke any more. Time spent waiting while a computer boots, or reboots to apply an update, or sits there doing who-knows-what in one of those sulky pauses, is time when we could be getting on with our work. Those delays cost real money, every day. They are also aggravating, sometimes not only for the immediate user. If I am on the telephone, for example, Outlook's slowness is not only a problem for me, but also for someone else trying to arrange a meeting.

I suspect that Microsoft made two wrong assumptions. First, that hardware improvements would remove performance issues. Fast hardware does mitigates problems, but really only disguises rather than fixes slow code. Further, the popularity of mini-laptops and other low-power devices means that fast hardware cannot be assumed. Second, Microsoft intended Vista to be always on, relying on sleep and resume instead of fast start-up. Unfortunately sleep and resume tends to be unreliable, and many Windows updates still require a system restart.

The same factors apply to web sites and web applications. One of the things that keeps people going back to Google is the consistently excellent performance of its site, especially in search. I am convinced that this has a subliminal impact, and that we instinctively prefer the sites that are more responsive. PHP inventor Rasmus Lerdorf speaks frequently about performance - last August at Drupalcon, for example - and is intolerant of slow applications; it would be great if more industry leaders shared his attitude.

There is little we can do about Windows boot times - well, apart from happy hours spent messing with msconfig, the System Configuration Utility - but that does not apply to our own development work. A project is not really done until the performance is satisfactory, even if all the other features work as specified. Performance is easy to measure, and there are plenty of profiling tools that show up bottlenecks in the code; tools like Rational PurifyPlus, Intel's VTune, or for .NET Redgate ANTS; there are also free tools available. The trick is to focus attention on what is too slow, rather than wasting time on what is already fast enough. It is rewarding work, since applications that perform well are a delight to use. Performance goes hand-in-hand with design, about which I posted a couple of weeks ago; they are both essential parts of the user experience, and a good user experience means a high level of satisfaction. There's nothing better for keeping customers coming back for more.

Technology moves at a fast pace. This fact is painfully apparent to anyone who's worked with it for more than a few years - both hardware and software evolve at an incredible rate, as do the skills required to use them. The tools we were using a decade ago are long obsolete, and even the languages we use evolve and are eventually replaced.

You don't necessarily need to learn whole new languages to keep up-to-date - sometimes just keeping abreast of language and framework revisions can help. Frameworks such as .NET are actively updated and refreshed, leading to the introduction of new language features (as with .NET 3.5), and new elements within the framework itself. Regardless of your chosen tools, keeping up with current trends and revisions is definitely a worthwhile undertaking.

The trick is, then, to make sure you are aware of any new developments - and this means you'll have to spend some time keeping track of what's going on in the world of programming.

Blogs and other technically-oriented sites are a good way of doing this - from the official development blogs to the unofficial commentary, ensuring you have a few relevant RSS feeds in your reader is an easy way to keep up with changes.

Getting to grips with something new is an altogether different challenge to that of simply being aware of changes. Reading blogs and news articles will only get you so far - if you want to learn a new concept, or language - then you'll have to dive in and get your hands dirty.

There is a wealth of information on new technologies to be found in books - for every aspect of computer science, for every language - you can be sure to find some resource available in print. I have a healthy library of technical books over a wide gamut of topics, although I must confess I haven't had the time to read all of them from cover-to-cover - but those that I have read have served me well.

As comprehensive as a book can be, technical literature can be a little dry so you need to be disciplined in order to get through them. Reading (even just skimming) a chapter a night is a good way of introducing yourself to a topic, and needn't take up too much time. As you gain a familiarity with the topic you can revisit the book for a more in-depth look at a particular subject, using the book as a specific reference rather than an introductory tome.

You don't need to spend money on books if you're on a budget, either - there is much in the way of reference material and tutorials available online, if you can find them. If you couple this use of reference books with judicious use of online tutorials, and getting hands-on with actual usage of new technology, then you should fare much better in terms of keeping up.

Working in technology requires lifelong learning - there will always be new versions of software, new platforms and new languages to replace the old. Very few developers will have the luxury of working with the same systems for a long period of time - while those maintaining legacy systems or content with older languages may be in a relatively unchanging environment, for most of us there is the challenge of keeping out skills current.

It's tough - particularly if you spend your time developing for a particular platform rather than learning the next, but it's important to keep yourself employable in the future. If you're in a comfortable development position for a long period of time, you may be tempted to just coast along with your current skills, but should you ever find yourself looking for work, you could be at a disadvantage.

Over the weekend Microsoft's Scott Guthrie, Coporate VP of the .NET developer division, announced that the open source jQuery Javascript library will be integrated into Visual Studio, the main Windows development tool. Further, Microsoft will treat jQuery as a supported product within technical support contracts, and will use jQuery to build new controls for ASP.NET, its web platform.

This is a breakthrough both for Microsoft and for open source. In the past, Microsoft has preferred to reinvent the wheel rather than adopting existing open source code. For example, when the company delivered Visual Studio Team System, it did not use existing open source products like NUnit for unit testing, or Subversion for source code management, or Nant and CruiseControl for build management, but shipped all-new equivalents. That strategy may have backfired. At the recent Remix08 conference in Brighton, I noticed that when a developer asked about Team System during a panel discussion, he was immediately advised by several other delegates to stick with the open source products.

I don't mean to suggest that Microsoft has only just discovered open source. After all, the company has its own open source community focused on interoperability, and publishes source code to some of this products under various shared source licenses. On the developer side, Microsoft sponsors significant open-source products like IronPython and IronRuby. But the jQuery case is particularly interesting, because Microsoft already has its own Javascript library called ASP.NET AJAX.
 
Is Microsoft now abandoning its own library? At Remix08, I asked Guthrie this very question. "We are definitely still investing in ASP.NET AJAX, there's lots of features coming out," he told me. "But there's a proportion of developers coming from other platforms where having support for other AJAX frameworks makes it more likely they'll use Visual Studio, which is good for us, and there's some proportion of developers on .NET that would prefer to use other frameworks in addition. People tend to be pragmatic. jQuery is great for CSS selectors and for the animation engine, but doesn't have a type system like Prototype or ASP.NET AJAX. We see a lot of developers wanting to use the ASP.NET AJAX class and type system, and then use CSS selectors and animation from jQuery."

In his announcement, Guthrie explains how jQuery support came about. Developers were asking for features to be added to ASP.NET AJAX, when they were already in jQuery. "As the team started to investigate building it, though, they quickly realized that the jQuery support for these scenarios is already excellent, and that there is a huge ecosystem and community built up around it." That sounds like common sense to most of us, but getting to this point has been a considerable journey for Microsoft.

The move is not without risks. If jQuery is good enough, then what about PHP, an open source alternative to ASP.NET? What about using Linux instead of Windows, or OpenOffice instead of Microsoft Office? The company can hardly suggest that open source stuff is never any good, when it is integrating open source code into its own products. Instead, Microsoft has to compete on real-world issues like quality, productivity, reliability and support, which can only be good for its customers.

"Developers, Developers, Developers" is the famous rant of Microsoft's Steve Ballmer. Maybe he picked the wrong word. I'm just back from the Remix 08 conference in Brighton, where the company's Principal Researcher Bill Buxton spoke on software design. He made a big impression, especially when he suggested in an interview that unless Microsoft changes its culture in a way that put design at the core of its software, the company would die.

Underlying this is the ascendancy of Apple, widely admired for its design, and the mixed fortunes of Windows Vista, which was meant to have great design but in practice has plenty of irritations many of which are design issues. There is a tendency to think of design as primarily about graphics and layout, but this view is too narrow. Design is about the user's experience, and encompasses all kinds of user interaction.

Few companies have the resources of Apple or Microsoft; but raised expectations of what constitutes good or even acceptable design affect the whole industry, including developers of internal applications as well as web site authors. Design failures are frustrating for users; and the consequence is that software is used less, and satisfaction is lower.

An example which comes to mind has no graphics at all. A certain telecom company with a colourful name has a telephone menu system which is unavoidable if you need to call support. Whenever I have to use it, I feel my blood pressure rising before dialling the number. I know I will have to go through numerous layers before being allowed to speak to a human. I know I will be given mandatory choices, none of which apply to me, forcing me to lie. I know each step will be ponderous, with a recorded messages I have heard before, and invitations to use the web site instead - if I thought that would do, why would I call? If you call outside working hours, you are taken through all the steps and told right at the end that the office is closed, goodbye. When I do eventually speak to someone, I am already in a bad temper.

This is the consequence of poor design. I could reel off countless further examples, such as Microsoft Outlook 2007, with its obscure dialogs - click Message Options to show email headers, very clear NOT - its habit of blaming the user for its own shortcomings, "The data file was not closed properly," and its slow performance with large mailboxes. Some of these are technical issues, but because they directly damage the user experience, they are also design problems.

Enough ranting. The interesting question is how developers and designers can work together to improve software design at every level. Buxton talks about continuous design, where designers participate in the development process throughout, rather than only at the beginning of a project, or even worse, only at the end. It is a good thought; but as the panel discussions at Remix demonstrated, there is no consensus about how the developer/designer relationship should work.

There are signs of change. Tools are appearing which have both developers and designers in mind, such as Microsoft's Expression Blend which can open Visual Studio solutions, or Adobe's product codename Thermo, which converts artwork into application code. That said, it is people rather than tools that hold the key. It is about developers ceding some of their power to designers; and about designers learning more about the constraints under which developers work; and about learning to treat poor user experience as a defect. It is not easy; but teams that get this right will gain a substantial commercial advantage.

Every company has its own culture - a unique blend of methodologies and people that form the working environment. The world of IT perhaps boasts some of the most diverse conditions - partly due to the diverse range of skills within, and partly due to misconceptions around the requirements of technical workers.

Good Practices, Best Practices and the Worst

There are generally two ways to get something done: There's the quick way, and then there's the right way. The right way isn't always the cheapest, nor is it feasible in some cases, but it generally pays greater dividends than the shortcuts in the long run.

For programmers, there are a number of indicators of a given environment's preferred approach. Source control, testing and documentation are all part of a good programmer's vocabulary, and are key indicators of how the programmer (and the department/team they are a part of) will work.

Such things as source control, testing and documentation are not always required - indeed, quite often they are overkill - but the lack of such procedure within core projects is a sign that the environment within the organisation in question may tend towards the 'quick and dirty' school of development.

For critical business development, safeguards such as source control and testing act not as impediments but as a hedge against potential failures - failures that can (and frequently do) cost more than the relatively minor time invested in such safeguards.

Documentation, in the same way, is a pre-emptive investment in a developer's time made with the intent of saving effort in the future - for improved ease of redevelopment, or for training purposes. A little time spent doing things in the correct way can pay greater dividends in the future.

The use of such tools and methods will heavily influence a working environment - for instance, in a situation without documentation or testing, a developer might find themselves bogged down with an endless stream of bug reports, whilst struggling to get to grips with an existing system. This cycle can be exacerbated by pressure to enhance or release new features - and such pressure usually comes from above.

Management Styles

The way an organisation is managed will have a direct effect on the working environment for IT staff. A better working environment will stem from more technically-aware management, with less focus on continually churning releases and new features and with at least some investment on some of the methods and tools mentioned above.

Those organisations that choose to ignore such needs will inevitably waste time dealing with the problems that arise, and inevitably it is the developers that have to deal with these problems. It is usually far better for an organisation to invest at least some time in defensive measures against future problems.

Of course, some places do - indeed, some places will adhere to protocols to their own detriment - but in my experience there are a great many that do not adhere to any sort of routine, and suffer as a result.

Improving Working Environment Factors

In some cases, bad practice is endemic- and as such it's not always easy to rally against deep-set problems with department work flow or with management interference, but being aware of the issues involved with a particular environment is the first step to making improvements.

An effort to improve the safeguards in place in the development work cycle (such as proper source control, testing and documentation) should be a priority, as in the long term they can save time from bug fixing premature releases. In addition, a good IT manager will also be aware of the best practices for developers, and will serve as a go-between from the developers to the exterior management.