Once upon a time there
lived a project manager (named, curiously enough, Fred Emperor) whose
only worry in life was to keep up with the latest trends in development
techniques. He changed methodology almost every project and loved to
show off his knowledge to management.

Word of Emperor’s habits spread over his department and
beyond into Internet newsgroups. Two gurus who had heard of the project
manager’s fashion consciousness decided to take advantage of it. They
introduced themselves via e-mail with a scheme in mind.

“We are a pair of very good programmers, and after many
years of research we have invented an extraordinary development process
of such agility that the cost of changing requirements has been reduced
nearly to zero. As a matter of fact, we have flattened out the famous
cost-to-fix- defect exponential curve that Barry Boehm presented in Software
Engineering Economics!” they wrote.

One of Emperor’s programmers heard the gurus’ strange
story and notified Emperor, whose curiosity got the better of him. He
decided to see the two scoundrels.

“Besides reducing the cost of changing requirements,
sir, we’ve eliminated the need for up-front design (this is such a
silly concept with our new method that we call it BDUF, short for ‘Big
Design Up Front’) and, of course, your programmers will never have to
waste any time documenting their work, for all the code is
self-documenting. One important thing, though: You must be aware that
closed-minded people on your staff might tell you that this approach
can’t possibly work. Always remember that this is a sure sign that
these people are afraid, and do not take these fearful opinions
seriously. In fact, you’d be better off getting rid of these cowards,”
the two gurus informed Emperor.

Emperor gave the two men a contract to build a payroll
system in exchange for their promise to begin working on the project
immediately. “Tell us what you need to get started and we’ll give it to
you. Just remember, the payroll system must be done in 4 years before
our mainframes drop dead,” said Emperor.

The two gurus asked for a big room with lots of
computers running Smalltalk and a large stack of index cards, and then
began working. They also asked for a full-time “customer,” who they
called a “goal donor,” to live in the room with the Smalltalk
programmers. The project manager looked around and, finding all of his
key employees busy, he grabbed the first person he could find hanging
around near the coffee machine and tossed him in the room with the
programmers.

Emperor thought he had spent his money quite well—in addition to getting
a new project completed that he could feel forever free to change the
requirements of at any time, he would discover which of his programmers
could churn out the most code in the shortest time, and which of his
programmers were cowardly dogs, so he could get rid of them. A few days
later, he called the old and wise chief technical officer (CTO), who
was considered by everyone to be a man with common sense. “Go and see
how the work is proceeding,” Emperor told the CTO, “and come back to
let me know.”

The CTO was welcomed by the two gurus. “We’ve built and
tested the system 17 times since Tuesday,” they said. “We’re almost
finished, but we need a few more cases of Pepsi, more computers to run
our regression test suites on, some chocolate-chip cookies (coding is
hungry work, indeed), and special desks with two chairs, for we always
program in pairs to compensate for not doing any up-front design. We’ve
made extra certain to turn a blind eye toward future requirements and
only to build what we need today. Here, Excellency! Admire the test
scores—feel the agility of the process!”

The CTO bent over the stack of index cards and tried to
see the architecture that was not there. He felt cold sweat on his
forehead.

“I can’t see any architecture,” he thought. “If I see
nothing, that means I’m stupid! Or worse, incompetent!” If the CTO
admitted that he didn’t see anything, Emperor might claim he was
incompetent and try to take his job.
“What a marvelous architecture,” he said. “I’ll
certainly tell Mr. Emperor.” The two gurus rubbed their hands
gleefully. They had almost made it. More Pepsi, 18 bags of potato
chips, and a couple of ping-pong tables were requested to finish the
work.

Finally, Emperor received the announcement that the two
gurus had the payroll system up and running. They came to Emperor’s
office to demonstrate it for him.

“Come in,” said Emperor. Even as they bowed, the two
gurus pretended that their system, which had been designed to
DoTheSimplestThingT hatCouldPossibly Work and could thus only pay a small
percentage of the employees, would scale to handle all of the
requirements.

“Here it is, Mr. Emperor, the result of our labor,” the
gurus said. “We have worked night and day (well, actually we knock off
at 5:00 PM every day because we want to stay fresh) but, at last, the
most agile process in the world is ready for you. Smell the code and
experience how fine it is.”

Of course, Emperor did not smell anything except a
faint odor of bubble gum and Scotch tape, and he could not see any
architecture between his fingers. He panicked and felt like fainting.
Luckily, his chair was right behind him, so he sat down. But when he
realized that no one could know that he did not see the architecture,
he felt better. Nobody could find out he was stupid and incompetent.
And Emperor didn’t know that everybody else around him thought and did
the very same thing.

The farce continued as the two gurus had foreseen it.
“Mr. Emperor, you’ll have to give us an open-ended variable-scope
contract in order for us to complete the payroll system,” the two gurus
said. “Our new process doesn’t operate well with fixed schedules or
budgets—fixed schedules give the code a funny smell.” Emperor was
annoyed, as he usually only used fixed-price contracts, but because
none of his bystanders seemed upset, he felt relieved.

“Yes, this is a beautiful process and it feels very
agile to me,” Emperor said, trying to look comfortable. “You’ve done a
fine job.”

The two gurus immediately started approaching publishing companies about
getting book contracts to popularize their new process.

“Mr. Emperor,” they said, “we have a request for you.
The people have found out about this extraordinary process and they are
anxious to learn more about it. Might we have permission to publish a
dozen or so books about our process that reference the work we’ve done
for you?” Emperor was doubtful about showing the details of his project
to the people, but then he abandoned his fears. After all, no one would
know about it except the ignorant and the incompetent.

“All right,” he said. “I will grant the people this
privilege.” Book contracts were signed, magazine articles were written,
and user conferences were scheduled in Italy. The gurus’ process was
given great credibility based on the claims of success on Emperor’s
project. Magazine editors and conference coordinators anxiously
scrutinized the ideas of the programmers across the industry. Everyone
wanted to know how stupid or incompetent his or her neighbor was but,
as the details of Emperor’s project were revealed, a strange murmur
rose from the crowd.

Alas, the goal donor whom Emperor had found by the
coffee machine turned out to be a new hire, right out of school, who
really didn’t understand the requirements of the payroll system and
completely missed the point that the mainframes were going to die in 4
years’ time. Encouraged by the gurus that changing requirements was no
problem due to the variable-scope contract they had received, the
project continued to consume soda, chips, and cookies for several years
while they were refactoring code, without actually progressing toward
completion. The two gurus assured the goal donor that this was no
problem, because SoftwareIsNeverDone . And ultimately Emperor had to
cancel the project, unfinished, which he did as soon as he realized
that his mainframe didn’t die.

Everyone said, loud enough for the others to hear, “Look at Emperor’s
new process. It’s the essence of agility!”

“What marvelous productivity!” “And the architecture!
The architecture that has emerged from the code! I have never seen
anything like it in my life.”

They all tried to conceal their disappointment at not
being able to see the architecture or smell the code, and because none
of them was willing to admit their own stupidity and incompetence, they
all behaved as the two gurus had predicted.

A young Java programmer from London, who was not afraid
and could only see things his eyes showed to him, put up a small Web
site with a contrary opinion. “Emperor’s process of
DesignAfterFirstTes ting is DAFT,” he said.

“ConstantRefactoring AfterProgramming is CRAP. The whole thing is a
bunch of daft crap, actually.”

“Fool!” he was reprimanded on the newsgroups. “You’re
afraid of agility!” But the young programmer’s remarks, which had been
heard by the bystanders, were repeated over and over again until
everyone cried, “This is just a bunch of daft crap!”

The book publishers realized that the people were
right but couldn’t admit to that. They thought it better to continue
the book series under the illusion that anyone who couldn’t smell the
code was either stupid or incompetent. And so books continued to roll
off the printing press.

http://www.sun.com/aboutsun/media/presskits/2009-0420/index.jsp

Sun and Oracle announced a definitive agreement for Oracle to acquire Sun for $9.50 per share in cash. The Sun Board of Directors has unanimously approved the transaction. It is anticipated to close this summer.

—————-

http://finance.yahoo.com/news/Oracle-Buys-prnews-14969049.html

REDWOOD SHORES, Calif., April 20 /PRNewswire-FirstCall/ — Oracle Corporation (Nasdaq: ORCL – News) and Sun Microsystems (Nasdaq: JAVA – News) announced today they have entered into a definitive agreement under which Oracle will acquire Sun common stock for $9.50 per share in cash. The transaction is valued at approximately $7.4 billion, or $5.6 billion net of Sun’s cash and debt. “We expect this acquisition to be accretive to Oracle’s earnings by at least 15 cents on a non-GAAP basis in the first full year after closing. We estimate that the acquired business will contribute over $1.5 billion to Oracle’s non-GAAP operating profit in the first year, increasing to over $2 billion in the second year. This would make the Sun acquisition more profitable in per share contribution in the first year than we had planned for the acquisitions of BEA, PeopleSoft and Siebel combined,” said Oracle President Safra Catz.

Related Quotes

Symbol	Price	Change
JAVA	9.20	-0.01
ORCL	19.79	+0.11

{“s” : “java,orcl”,”k” : “c10,l10,p20,t10″,”o” : “”,”j” : “”}

(Logo: http://www.newscom.com/cgi-bin/prnh/20020718/ORCLLOGO)

“The acquisition of Sun transforms the IT industry, combining best-in-class enterprise software and mission-critical computing systems,” said Oracle CEO Larry Ellison. “Oracle will be the only company that can engineer an integrated system – applications to disk – where all the pieces fit and work together so customers do not have to do it themselves. Our customers benefit as their systems integration costs go down while system performance, reliability and security go up.”

There are substantial long-term strategic customer advantages to Oracle owning two key Sun software assets: Java and Solaris. Java is one of the computer industry’s best-known brands and most widely deployed technologies, and it is the most important software Oracle has ever acquired. Oracle Fusion Middleware, Oracle’s fastest growing business, is built on top of Sun’s Java language and software. Oracle can now ensure continued innovation and investment in Java technology for the benefit of customers and the Java community.

The Sun Solaris operating system is the leading platform for the Oracle database, Oracle’s largest business, and has been for a long time. With the acquisition of Sun, Oracle can optimize the Oracle database for some of the unique, high-end features of Solaris. Oracle is as committed as ever to Linux and other open platforms and will continue to support and enhance our strong industry partnerships.

“Oracle and Sun have been industry pioneers and close partners for more than 20 years,” said Sun Chairman Scott McNealy. “This combination is a natural evolution of our relationship and will be an industry-defining event.”

“This is a fantastic day for Sun’s customers, developers, partners and employees across the globe, joining forces with the global leader in enterprise software to drive innovation and value across every aspect of the technology marketplace,” said Jonathan Schwartz, Sun’s CEO, “From the Java platform touching nearly every business system on earth, powering billions of consumers on mobile handsets and consumer electronics, to the convergence of storage, networking and computing driven by the Solaris operating system and Sun’s SPARC and x64 systems. Together with Oracle, we’ll drive the innovation pipeline to create compelling value to our customer base and the marketplace.”

“Sun is a pioneer in enterprise computing, and this combination recognizes the innovation and customer success the company has achieved. Our largest customers have been asking us to step up to a broader role to reduce complexity, risk and cost by delivering a highly optimized stack based on standards,” said Oracle President Charles Phillips. “This transaction will preserve and enhance investments made by our customers, while we continue to work with our partners to provide customers with choice.”

The Board of Directors of Sun Microsystems has unanimously approved the transaction. It is anticipated to close this summer, subject to Sun stockholder approval, certain regulatory approvals and customary closing conditions.

There will be a conference call today to discuss the transaction at 5:30 a.m. Pacific time. Investors can listen to the conference call by dialing (719) 234-7870, passcode 923645. A replay will be available for 24 hours after the call ends at (719) 884-8882, passcode: 923645. A live audio webcast of the call will be made available at www.oracle.com/investor and a replay will be available for seven days after the call ends.

About Oracle

Oracle (NASDAQ: ORCL – News) is the world’s largest enterprise software company. For more information about Oracle, please visit our Web site at http://www.oracle.com.

About Sun Microsystems

Sun Microsystems, Inc. (NASDAQ: JAVA – News) develops the technologies that power the global marketplace. Guided by a singular vision — “The Network is the Computer” — Sun drives network participation through shared innovation, community development and open source leadership. Sun can be found in more than 100 countries and on the Web at http://www.sun.com.

Trademarks

Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

Sun, Sun Microsystems, the Sun logo, Java, Solaris and the Network is the Computer are trademarks or registered trademarks of Sun Microsystems, Inc. or its subsidiaries in the United States and other countries.

Cautionary Statement Regarding Forward-Looking Statements

This press release contains certain forward-looking statements about Oracle and Sun, including statements that involve risks and uncertainties concerning Oracle’s proposed acquisition of Sun, anticipated product information, estimates of future results of operations and general business outlook. When used in this press release, the words “anticipates”, “estimates”, “may”, “can”, “will”, “believes”, “expects”, “projects”, “intends”, “likely”, similar expressions and any other statements that are not historical facts are intended to identify those assertions as forward-looking statements. Any such statement may be influenced by a variety of factors, many of which are beyond the control of Oracle or Sun, that could cause actual outcomes and results to be materially different from those projected, described, expressed or implied in this press release due to a number of risks and uncertainties. Potential risks and uncertainties include, among others, the possibility that the transaction will not close or that the closing may be delayed, the anticipated synergies of the combined companies may not be achieved after closing, the combined operations may not be successfully integrated in a timely manner, if at all, general economic conditions in regions in which either company does business, and the possibility that Oracle or Sun may be adversely affected by other economic, business, and/or competitive factors. Accordingly, no assurances can be given that any of the events anticipated by the forward-looking statements will transpire or occur, or if any of them do so, what impact they will have on the results of operations or financial condition of Oracle or Sun.

In addition, please refer to the documents that Oracle and Sun, respectively, file with the Securities and Exchange Commission (the “SEC”) on Forms 10-K, 10-Q and 8-K. These filings identify and address other important factors that could cause Oracle’s and Sun’s respective financial and operational results to differ materially from those contained in the forward-looking statements set forth in this document. You are cautioned to not place undue reliance on forward-looking statements, which speak only as of the date of this report. Neither Oracle nor Sun is under any duty to update any of the information in this release.

Additional Information about the Merger and Where to Find It

In connection with the proposed merger, Sun will file a proxy statement with the SEC. Additionally, Sun and Oracle will file other relevant materials in connection with the proposed acquisition of Sun by Oracle pursuant to the terms of an Agreement and Plan of Merger by and among Oracle, Soda Acquisition Corporation, a wholly-owned subsidiary of Oracle, and Sun. The materials to be filed by Sun with the SEC may be obtained free of charge at the SEC’s web site at www.sec.gov. Investors and security holders of Sun are urged to read the proxy statement and the other relevant materials when they become available before making any voting or investment decision with respect to the proposed merger because they will contain important information about the merger and the parties to the merger.

Oracle, Sun and their respective directors, executive officers and other members of its management and employees, under SEC rules, may be deemed to be participants in the solicitation of proxies of Sun stockholders in connection with the proposed merger. Investors and security holders may obtain more detailed information regarding the names, affiliations and interests of certain of Oracle’s executive officers and directors in the solicitation by reading the proxy statement and other relevant materials filed with the SEC when they become available. Information concerning the interests of Sun’s participants in the solicitation, which may, in some cases, be different than those of Sun’s stockholders generally, is set forth in the materials filed with the SEC on Form 10-K and will be set forth in the proxy statement relating to the merger when it becomes available.

Write Dumb Code — Advice From Four Leading Java Developers

By Janice J. Heiss, April 2009 <!– –> E-mail      Print-friendly Version    Download Over the years, developers have talked about their favorite code, funniest code, most beautiful code, how to write code, how not to write code, the obstacles to writing good code, what they love and hate about writing code, the process of writing code, and so on. In the process, they have provided a lot of insight that is worth preserving. In the first of a multipart series, we begin with some general advice: Write dumb code. Contents - Brian Goetz: Write Dumb Code - Heinz Kabutz: Classify “Goodness” by Using Good Object-Oriented Design Patterns - Cay Horstmann: Patterns Are Not Magic Potions - Kirk Pepperdine: Dumb Code Is More Readable - See Also - Discuss Brian Goetz: Write Dumb Code Brian Goetz Sun Microsystems technology evangelist Brian Goetz has, since 2000, published some 75 articles on best practices, platform internals, and concurrent programming. He is the principal author of the book Java Concurrency in Practice, a 2006 Jolt Award Finalist and the best-selling book at the 2006 JavaOne conference. Prior to joining Sun in August of 2006, he was a consultant for 15 years for his software firm, Quiotix, where, in addition to writing about Java technology, he spoke frequently at conferences and gave presentations on threading, the Java programming language memory model, garbage collection, Java technology performance myths, and other topics. In addition, he has consulted on kernel internals, device drivers, protocol implementations, compilers, server applications, web applications, scientific computing, data visualization, and enterprise infrastructure tools. Goetz has participated in a number of open-source projects, including the Lucene text search and retrieval system, and the FindBugs static analysis toolkit. At Sun, he serves as a consultant on a wide range of topics that extend from Java concurrency to the needs of Java developers, and he contributes to the development of the Java platform. How can developers write Java code that performs well? The answer may seem counterintuitive. Often, the way to write fast code in Java applications is to write dumb code — code that is straightforward, clean, and follows the most obvious object-oriented principles. This has to do with the nature of dynamic compilers, which are big pattern-matching engines. Because compilers are written by humans who have schedules and time budgets, the compiler developers focus their efforts on the most common code patterns, because that’s where they get the most leverage. So if you write code using straightforward object-oriented principles, you’ll get better compiler optimization than if you write gnarly, hacked-up, bit-banging code that looks really clever but that the compiler can’t optimize effectively. “Often, the way to write fast code in Java applications is to write dumb code — code that is straightforward, clean, and follows the most obvious object-oriented principles.” Brian Goetz Technology Evangelist Sun Microsystems So clean, dumb code often runs faster than really clever code, contrary to what developing in C might have taught us. In C, clever source code turns into the expected idiom at the machine-code level, but it doesn’t work that way in Java applications. I’m not saying that the Java compiler is too dumb to translate clever code into the appropriate machine code. It actually optimizes Java code more effectively than does C. My advice is this: Write simple straightforward code and then, if the performance is still not “good enough,” optimize. But implicit in the concept of “good enough” is that you need to have clear performance metrics. Without them, you’ll never know when you’re done optimizing. You’ll also need a realistic, repeatable testing program in place to determine if you’re meeting your metrics. Once you can test the performance of your program under actual operating conditions, then it’s OK to start tweaking, because you’ll know if your tweaks are helping or not. But assuming, “Oh, gee, I think if I change this, it will go faster,” is usually counterproductive in Java programming. Because Java code is dynamically compiled, realistic testing conditions are crucial. If you take a class out of context, it will be compiled differently than it will in your application, which means performance must be measured under realistic conditions. So performance metrics should be tied to indices that have business value — transactions per second, mean service time, worst-case latency — factors that your customers will perceive. Focusing on performance characteristics at the micro level is often misleading and difficult to test, because it’s hard to make a realistic test case for some small bit of code that you’ve taken out of context. In 2003, you said, “Developers love to optimize code and with good reason. It is so satisfying and fun. But knowing when to optimize is far more important. Unfortunately, developers generally have horrible intuition about where the performance problems in an application will actually be.” Do you still believe this? It’s truer today than it was four years ago, and more true for Java developers than it was for C. Most performance tuning reminds me of the old joke about the guy who’s looking for his keys in the kitchen even though he lost them in the street, because the light’s better in the kitchen. We’re intimately familiar with the code that we write. The external services that we depend on, whether libraries or external agents, such as databases and web services, are out of sight and out of mind. So when we see a performance problem, we tend to think about places in our code that we can imagine being performance problems. But often, that’s not the source of the performance problem — it’s somewhere else in the application’s architecture. Most performance problems these days are consequences of architecture, not coding — making too many database calls or serializing everything to XML back and forth a million times. These processes are usually going on outside the code you wrote and look at every day, but they are really the source of performance problems. So if you just go by what you’re familiar with, you’ll be looking for your keys in the kitchen. This is a mistake that developers have always been subject to, and the more complex the application, the more it depends on code you didn’t write. Hence, the more likely it is that the problem is outside of your code. Performance analysis is much harder in the Java programming language than in C where it is more straightforward, because C bears a significant similarity to assembly language. The mapping from C code to machine code is fairly direct. To the extent that it isn’t, the compiler can show you the machine code. Java applications don’t work like C. The runtime constantly modifies the code based on changing conditions and observations. It starts out interpreting the code and then compiles it. It may invalidate the compiled code and recompile it based on information from profiling data or from loading other classes. As a result, the performance characteristics of your code will vary dramatically depending on the environment the code runs in. That makes it harder to say “This code is faster than that code” because you have to account for more context to make a reasonable performance analysis. There are also nondeterministic factors such as the timing and nature of compilation, the interaction of the loaded classes, and garbage collection. So it’s harder to do the kind of microperformance optimization with Java code that one can do in C. At the same time, the fact that the compilation is done at execution time means that the optimizer has far more information to work with than the C compiler does. It knows what classes are loaded and how the method being compiled has actually been used. As a result, it can make far better optimization decisions than a static compiler could. This is great for performance but means it’s harder to predict the performance of a given block of code. Read the full interview with Brian Goetz. Heinz Kabutz: Classify “Goodness” by Using Good Object-Oriented Design Patterns Heinz Kabutz Java Champion Heinz Kabutz was raised in Cape Town, South Africa, where he developed a love of programming in junior high school through his explorations on a ZX Spectrum computer. He received a B.S. from the University of Cape Town, and at 25, a Ph.D., both in computer science. In 1998, he started his own software development company, Java Specialists, where he writes contract software, consults, and offers courses on Java technology and design patterns. Kabutz is best known as the creator of the free Java Specialists’ Newsletter, targeted to expert Java developers. I asked Kabutz to respond to Brian Goetz’s advice to write “dumb” code. “What is good code? I find it easier to classify ‘goodness’ by using good object-oriented design patterns. I usually encourage software development companies to train all of their programmers in design patterns, from the most junior to the wise architect.” Heinz Kabutz Java Champion and Creator of the Java Specialists’ Newsletter In my experience, good object-oriented design tends to produce faster and more maintainable Java code. But what is good code? I find it easier to classify “goodness” by using good object-oriented design patterns. I usually encourage software development companies to train all of their programmers in design patterns, from the most junior to the wise architect. Teams that employ good design patterns find it much easier to tune their code, which will be less brittle and require less copying and pasting. The java.util.Arrays class is a good example of bad code. It contains two mergeSort(Object[]) methods, one taking a Comparator, the other using Comparable. The methods are virtually identical and could have been merged into one with the introduction of a DefaultComparator that would use the Comparable method. The strategy pattern would have avoided this design flaw. Coding by Ctrl-C and Ctrl-V can also hide performance problems. Let’s assume you have several algorithms, all virtually identical, but in different parts of your system. If you measure performance, you might find that each of the algorithms takes 5 percent of your CPU, but if you add them up, they amount to 20 percent. Good design allows you to more easily change code and detect bottlenecks. Let me give an example to prove Brian Goetz’s point. In the early days of Java programming, I sometimes resorted to “clever” coding. For example, when I was optimizing a system written by a company in Germany, I changed the String addition to use StringBuffer after we had optimized the architecture and design of the system and wanted to improve things a bit. Don’t read too much into microbenchmarks. Performance advantages come from good design and an appropriate architecture. We start with a basic concatenation based on +=: public static String concat1(String s1, String s2, String s3, String s4, String s5, String s6) { String result = ""; result += s1; result += s2; result += s3; result += s4; result += s5; result += s6; return result; } String is immutable, so the compiled code will create many intermediate String objects, which can strain the garbage collector. A common remedy is to introduce StringBuffer, causing it to look like this: public static String concat2(String s1, String s2, String s3, String s4, String s5, String s6) { StringBuffer result = new StringBuffer(); result.append(s1); result.append(s2); result.append(s3); result.append(s4); result.append(s5); result.append(s6); return result.toString(); } But the code is becoming less legible, which is undesirable. Using JDK 6.0_02 and the server HotSpot compiler, I can execute concat1() a million times in 2013 milliseconds, but concat2() in 734 milliseconds. At this point, I might congratulate myself for making the code three times faster. However, the user won’t notice it if 0.1 percent of the program becomes three times faster. Here’s a third approach that I used to make my code run faster, back in the days of JDK 1.3. Instead of creating an empty StringBuffer, I sized it to the number of required characters, like so: public static String concat3(String s1, String s2, String s3, String s4, String s5, String s6) { return new StringBuffer( s1.length() + s2.length() + s3.length() + s4.length() + s5.length() + s6.length()).append(s1).append(s2). append(s3).append(s4).append(s5).append(s6).toString(); } I managed to call that a million times in 604 milliseconds. Even faster than concat2(). But is this the best way to add the strings? And what is the simplest way? The approach in concat4() illustrates another way: public static String concat4(String s1, String s2, String s3, String s4, String s5, String s6) { return s1 + s2 + s3 + s4 + s5 + s6; } You can hardly make it simpler than that. Interestingly, in Java SE 6, I can call the code a million times in 578 milliseconds, which is even better than the far more complicated concat3(). The method is cleaner, easier to understand, and quicker than our previous best effort. Sun introduced the StringBuilder class in J2SE 5.0, which is almost the same as StringBuffer, except it’s not thread-safe. Thread safety is usually not necessary with StringBuffer, since it is seldom shared between threads. When Strings are added using the + operator, the compiler in J2SE 5.0 and Java SE 6 will automatically use StringBuilder. If StringBuffer is hard-coded, this optimization will not occur. When a time-critical method causes a significant bottleneck in your application, it’s possible to speed up string concatenation by doing this: public static String concat5(String s1, String s2, String s3, String s4, String s5, String s6) { return new StringBuilder( s1.length() + s2.length() + s3.length() + s4.length() + s5.length() + s6.length()).append(s1).append(s2). append(s3).append(s4).append(s5).append(s6).toString(); } However, doing this prevents future versions of the Java platform from automatically speeding up the system, and again, it makes the code more difficult to read. Read the full interview with Heinz Kabutz. Cay Horstmann: Patterns Are Not Magic Potions Cay Horstmann “I’ve had too many junior programmers sprinkle patterns over their code in the hope of improving it. Patterns are not magic potions, and it takes quite a bit more experience than is commonly acknowledged to use them wisely.” Cay Horstmann Java Champion and Professor of Computer Science at San Jose State University Java Champion Cay Horstmann grew up in northern Germany and attended the Christian-Albrechts-Universität in Kiel, a harbor town by the Baltic Sea. With an M.S. in computer science from Syracuse University and a Ph.D. in mathematics from the University of Michigan, he is now a professor of computer science at San Jose State University in California. He was formerly a VP and CTO of a dot-com startup and, previous to that, owner of a successful company that sold a DOS program for editing scientific documents. In his spare time, Horstmann consults in Internet programming. I agree with Brian Goetz. I learned over the years that it never pays to optimize code until after you profile. We all fret over caching values rather than recomputing them, eliminating layers, and so on. More often than not, it makes little difference in performance but introduces a huge headache in debugging. I saw that you asked Heinz Kabutz the same question. He says, “I usually encourage software development companies to train all of their programmers in design patterns, from the most junior to the wise architect.” I’m a bit uncomfortable with this. I agree that patterns should be a part of everyone’s education, but I’ve had too many junior programmers sprinkle patterns over their code in the hope of improving it. Patterns are not magic potions, and it takes quite a bit more experience than is commonly acknowledged to use them wisely. Take the Java I/O library, which is imbued with the value of the decorator pattern. For example, BufferedReader is a decorator, and to get buffered reading from a file, you do this: Reader reader = new BufferedReader(new FileReader("foo.txt")); What if you also want lookahead? Now you need to insert a PushbackReader into the decorator chain. What a pain! I would have preferred more usability and less pattern dogma. In C++, buffering and lookahead are part of every file stream, which is so much more convenient in practice. Read the full interview with Cay Horstmann. Kirk Pepperdine: Dumb Code Is More Readable Kirk Pepperdine Java Champion Kirk Pepperdine is a primary contributor to javaperformancetuning.com, which is widely regarded as the premier site for Java performance tuning information, and is the coauthor of Ant Developer’s Handbook. He has been heavily involved in application performance since the beginning of his programming career and has tuned applications in a variety of languages: Cray Assembler, C, Smalltalk, and, since 1996, Java technology. He has also worked on building middleware for distributed applications. He has worked with Cray supercomputers at the Canadian Department of Defense, as a consultant at Florida Power & Light, and as a senior consultant with GemStone Systems. He is currently an independent consultant and an editor at TheServerSide.com. I asked Pepperdine to respond to Brian Goetz. “Because we’re trained to look at code, when something goes wrong, we look at code. And no matter how good our code is, we can always find something wrong or ugly that’s begging to be fixed. Finding ugly code will throw even the best developers off track — because the code is ugly, they will guess that it’s the source of the problem.” Kirk Pepperdine Java Champion and Independent Consultant There are really two questions here: First, how does writing dumb code help with performance? And second, how does writing well-structured code help with performance? I’ll answer the “dumb code” one first. While we write code to run on a machine, the primary consumers of code are humans. Dumb code tends to be more readable and hence more understandable. If we can iron out the twists, then we have a better chance of avoiding the dumb mistakes that clever code may hide from us. HotSpot, IBM’s MMI, and the JIT are tools that work to optimize our code for us through dynamic profiling. Complex code tends to confuse these tools, so that they provide either suboptimal optimizations or no optimizations at all. We can see this with a well-written microperformance benchmark. Most of the code in a well-written microbenchmark is there to confuse the JIT so that it doesn’t translate our code into something that no longer measures the effect we’re interested in. While a microbenchmark may be a pathological case, the same sorts of things can happen in our real application code. Another reason to write dumb code is that most of the complexities are due to some optimization that everyone thinks is needed. In many cases, these optimizations are premature. While I’m all for performance planning, I’m dead set against premature optimizations. When is a plan a plan, and when is it premature? I guess it’s a little like the difference between art and porn: You’ll know it when you see it. Which brings us to the second question — how does well-structured code help performance? Most performance problems can only be solved by adding or altering code in the application. I’ve found that if the code is well structured and loosely coupled, if the classes are cohesive, and the code uses delegation, I can avoid the whack-a-mole problem when I start to change code. This problem can also be called shotgun refactoring — if I make a change in one part of the application, other seemingly random parts of the application will break. And as I fix the breakage, I create a whole series of new breaks, and so on. So how can we avoid this? First, follow the DRY — Don’t Repeat Yourself — principle. Let’s look at collections as an example. We would traditionally manage a query against a collection in Java by creating an iterator: .... Iterator iter = customers.iterator(); while (iter.hasNext()) { Customer c = (Customer)iter.next(); doStuff( c); } .... Here’s the trap: If another part of our application needs to doStuff(), it’s likely that the code will get repeated either as a cut and paste or as simply rewritten. Either way, you’ve just violated DRY, which has numerous consequences. You’ve also neglected another design principle: Delegate, don’t assume (responsibility). By not delegating, you risk violating DRY. You certainly violate the principle of information hiding. Think of it this way: By doing a get, you’ve not only violated encapsulation but have tightly coupled your class to the callee. When you violate encapsulation by exporting state, you are forced to also export the application logic needed to manage that state and hence violate DRY. So you can see that this is wrong from many different perspectives. Here’s the big performance hit: Suppose the data structure that is being used is suboptimal, and suppose you recognize that it needs to be changed. If you’ve exported state and behavior using iterators or whatever, you’ve created the whack-a-mole problem. Take a look at what happens when we delegate: public class Customers { Hashmap customers = new Hashmap(); public void putCustomer( Customer customer) { allCustomers.put( customer.getId(), customer); } public Customer getCustomer( String id) { allCustomers.get( id); } public Customers getCustomers( String pattern) { return doSomeStufftoGetACollectionOfCustomer( pattern); } Here we have more code. But this is often the case when you demonstrate something in a tiny contrived example. You only see the benefits in large code bases, which, of course, make for horrible examples. That aside, we have a class that wraps our intended collection. Our new class is semantically in tune with our domain. How many problem domains contain the word Hashmap and how many domains contain Customers? So we’ve corrected our vocabulary. Next, we’ve provided a home for our queries, at least the queries that we’ve anticipated. If we get other patterns of queries, it may be possible to add in a secondary collection that is keyed differently. Think of it as adding another index on a database table. The beauty of it is that because I’ve encapsulated and delegated the calls, I’m free to make these changes unencumbered by what my clients may or may not know. In other words, no whack-a-mole. Furthermore, every client will realize the performance benefit of the optimization. So this is a win all the way round. I intentionally didn’t use generics. Using this development pattern, I don’t need compile-time type checking on the collection(s) because the class API provides all the safety that’s needed. I’ve always contended that it’s a mistake to expose a raw collection in an API, and because I never feel that the primary use case for generics is justified. But that’s another discussion. So what happens if someone needs a query that we haven’t provided? Closures might seem like a good solution, but they would have to be implemented very carefully or we could “closure” ourselves into a whack-a-mole problem. The closure would have to access only those elements that could be classified as nonprimitive, by which I mean those elements that can function without knowledge of the underlying structure. This is in contrast to a primitive method or a method that needs to understand the underlying data structure of the class. The point is to hide the implementation details to things outside of our domain. To summarize, performance tuning often requires that I touch code, which is not much different from refactoring. All of the arguments that the Agile crowd put forth — loose coupling, simple code, following good design patterns, having good unit testing in place, automated builds, and so on — also apply to performance tuning.

http://www.javabeat.net/articles/120-new-features-in-java-70-part-1-1.htmls

Introduction

This article discusses the new features that are available in Java 7.0. Java 7.0 comes with bunch of new features – language level changes as well as API level changes and this article concentrates on the new API features such as Cache API, New Date and Time API and New IO 2 as well as the language level changes in the form of Super packages. The readers are assumed that they are more familiar with the Java 5.0 language level changes such as Generics and Annotations. This article covers few of the new features in Java 7.0 and the remaining set of new features will be covered in the next article. It is likely that the APIs may undergo changes before the formal release of Java 7.0 happens. You can read Java 7.0 Articles.

New features in Java 7.0

The following new features will be discussed in detail in this article.

• Cache API
• Date and Time API
• New IO2
• Super Packages

Cache API

The Cache API provides the mechanism for storing and retrieving the objects. The API also provides a way to plug-in user defined Cache objects. The Cache API is relatively small and this section discusses the core classes and the interfaces available in the Cache API.

Cache Manager

The Cache Manager stands as the entry point for using Cache API. An instance of the CacheManager can be obtained using the following code,

CacheManager manager = CacheManager.getInstance();

This method will return a singleton object of type CacheManager. The cache manager also provides methods for registering and deregistering cache objects. Have a look at the following code,

Cache permanentCache = .... // an implementation of a permanent cache
manager.registerCache("PERM_CACHE", permanentCache);

Cache and CacheFactory

The API provides plug-in capabilities of custom implementation through the help of Cache and the CacheFactory interfaces. The Cache interface extends the Map interface so the put, get and iteration methods that are available in the map can be directly used. It is also possible to remove the objects in the cache that are no longer needed through the Cache.evict() method. CacheFactory is a service provider API and it provides a factory method for creating a Cache object from a map of properties.

CacheManager manager = CacheManager.getInstance();
CacheFactory factory = manager.getCacheFactory();

Map cacheProperties = ....;
Cache cacheObject = factory.createCache(cacheProperties);

An object is no longer needed in the cache if the expiration time set for the object expires and that’s where the CacheEntry object comes in.

CacheEntry

The interface provides certain useful information and operations that are applicable for an object in a cache such as the last access time, last update time, creation time, expiration time etc. Note that this interface directly extends Map.Entry interface. It is possible to obtain an instance of this object from the object’s key,

Cache permanentCache = .... // an implementation of a permanent cache
permanentCache.put("MYSTR", someStrObject);

CacheEntry entry = cache.getCacheEntry("MYSTR");

Cache Events

It is also possible to attach listeners to cache object when objects are stored, removed, loaded and evicted from the cache. An implementation of a cache listener could be,

SimpleCacheListener.java

class SimpleCacheListener implements CacheListener
{
    void onClear() {}

	void onEvict(Object key) {}

	void onLoad(Object key) {}

	void onPut(Object key) {}

	void onRemove(Object key) {}
}

This cache listener can be added to cache for receiving any events notification through the following code,

Cache cacheObject = ...;
cacheObject.addListener(new SimpleCacheListener());

http://www.sans. org/gssp/ essential_ skills_java. pdf

———————-

http://sourcemaking.com/design-patterns-and-tips

Design Patterns

Creational Patterns

1.

Abstract Factory
The purpose of the Abstract Factory is to provide an interface for creating families of related objects, without specifying concrete classes (more…)

2.

Builder
The Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations (more…)

3.

Factory Method
The Factory Method defines an interface for creating objects, but lets subclasses decide which classes to instantiate (more…)

4.

Object Pool
Object pools are used to manage the object caching and it can offer a significant performance boost (more…)

5.

Prototype
The Prototype pattern specifies the kind of objects to create using a prototypical instance. Prototypes of new products are often built prior to full production, but in this example, the prototype is passive and does not participate in copying itself (more…)

6.

Singleton
The Singleton pattern ensures that a class has only one instance and provides a global point of access to that instance (more…)

Structural Patterns

7.

Adapter
The Adapter pattern allows otherwise incompatible classes to work together by converting the interface of one class into an interface expected by the clients (more…)

8.

Bridge
The Bridge pattern decouples an abstraction from its implementation, so that the two can vary independently (more…)

9.

Composite
The Composite composes objects into tree structures and lets clients treat individual objects and compositions uniformly (more…)

10.

Decorator
The Decorator attaches additional responsibilities to an object dynamically. Decorator pattern suggests giving the client the ability to specify whatever combination of “features” is desired (more…)

11.

Facade
The Facade defines a unified, higher level interface to a subsystem that makes it easier to use (more…)

12.

Flyweight
The Flyweight pattern describes how to share objects to allow their use at fine granularities without prohibitive cost (more…)

13.

Private Class Data
The private class data design pattern seeks to reduce exposure of attributes by limiting their visibility (more…)

14.

Proxy
The Proxy provides a surrogate or place holder to provide access to an object (more…)

Behavioral Patterns

15.

Chain of Responsibility
Chain of Responsibility chains the receiving objects together, and then passes any request messages from object to object until it reaches an object capable of handling the message (more…)

16.

Command
The Command pattern allows requests to be encapsulated as objects, thereby allowing clients to be parameterized with different requests (more…)

17.

Interpreter
The Intepreter pattern defines a grammatical representation for a language and an interpreter to interpret the grammar (more…)

18.

Iterator
The Iterator provides ways to access elements of an aggregate object sequentially without exposing the underlying structure of the object. (more…)

19.

Mediator
The Mediator defines an object that controls how a set of objects interact. Loose coupling between colleague objects is achieved by having colleagues communicate with the Mediator, rather than with each other (more…)

20.

Memento
The Memento captures and externalizes an object’s internal state so that the object can later be restored to that state (more…)

21.

Null Object
The Null Object encapsulates the absence of an object by providing a substitutable alternative that offers suitable default “do nothing” behavior (more…)

22.

Observer
The Observer defines a one-to-many relationship so that when one object changes state, the others are notified and updated automatically (more…)

23.

State
The State pattern allows an object to change its behavior when its internal state changes (more…)

24.

Strategy
The Strategy lets the algorithm vary independently from the clients that use it. It defines a family of algorithms, encapsulates each one, and makes them interchangeable (more…)

25.

Template Method
The Template Method defines a skeleton of an algorithm in an operation, and defers some steps to subclasses (more…)

26.

Visitor
The Visitor pattern represents an operation to be performed on the elements of an object structure without changing the classes on which it operates (more…)

Composing Methods of Refactoring

27.

Extract Method
If you have a code fragment that can be grouped together, turn the fragment into a method whose name explains the purpose of the method (more…)

28.

Inline Method
If a method’s body is just as clear as its name, put the method’s body into the body of its callers and remove the method (more…)

29.

Inline Temp
If you have a temp that is assigned to once with a simple expression, and the temp is getting in the way of other refactorings, replace all references to that temp with the expression (more…)

30.

Introduce Explaining Variable
If you have a complicated expression, put the result of the expression, or parts of the expression, in a temporary variable with a name that explains the purpose (more…)

31.

Remove Assignments to Parameters
If the code assigns to a parameter, use a temporary variable instead (more…)

32.

Replace Method with Method Object
If uou have a long method that uses local variables in such a way that you cannot apply Extract Method, turn the method into its own object so that all the local variables become fields on that object (more…)

33.

Replace Temp with Query
If you are using a temporary variable to hold the result of an expression, extract the expression into a method. Replace all references to the temp with the expression. The new method can then be used in other methods (more…)

34.

Substitute Algorithm
If you want to replace an algorithm with one that is clearer, replace the body of the method with the new algorithm (more…)

Moving Features Between Objects

35.

Extract Class
If you have one class doing work that should be done by two, create a new class and move the relevant fields and methods from the old class into the new class (more…)

36.

Hide Delegate
If a client is calling a delegate class of an object, create methods on the server to hide the delegate (more…)

37.

Inline Class
If a class isn’t doing very much, move all its features into another class and delete it (more…)

38.

Introduce Foreign Method
If a server class you are using needs an additional method, but you can’t modify the class, create a method in the client class with an instance of the server class as its first argument (more…)

39.

Introduce Local Extension
If a server class you are using needs several additional methods, but you can’t modify the class, create a new class that contains these extra methods. Make this extension class a subclass or a wrapper of the original (more…)

40.

Move Field
If a field is, or will be, used by another class more than the class on which it is defined, create a new field in the target class, and change all its users (more…)

41.

Move Method
If a method is, or will be, using or used by more features of another class than the class on which it is defined, create a new method with a similar body in the class it uses most. Either turn the old method into a simple delegation, or remove it altogether (more…)

42.

Remove Middle Man
If a class is doing too much simple delegation, get the client to call the delegate directly (more…)

Organizing Data

43.

Change Bidirectional Association to Unidirectional
If you have a two-way association but one class no longer needs features from the other, drop the unneeded end of the association (more…)

44.

Change Reference to Value
If you have a reference object that is small, immutable, and awkward to manage, turn it into a value object (more…)

45.

Change Unidirectional Association to Bidirectional
If you have two classes that need to use each other’s features, but there is only a one-way link, add back pointers, and change modifiers to update both sets (more…)

46.

Change Value to Reference
If you have a class with many equal instances that you want to replace with a single object, turn the object into a reference object (more…)

47.

Duplicate Observed Data
If you have domain data available only in a GUI control, and domain methods need access, copy the data to a domain object. Set up an observer to synchronize the two pieces of data (more…)

48.

Encapsulate Collection
If a method returns a collection, make it return a read-only view and provide add/remove methods (more…)

49.

Encapsulate Field
If there is a public field, make it private and provide accessors (more…)

50.

Replace Array with Object
If you have an array in which certain elements mean different things, replace the array with an object that has a field for each element (more…)

51.

Replace Data Value with Object
If you have a data item that needs additional data or behavior, turn the data item into an object (more…)

52.

Replace Magic Number with Symbolic Constant
If you have a literal number with a particular meaning, create a constant, name it after the meaning, and replace the number with it (more…)

53.

Replace Record with Data Class
If you need to interface with a record structure in a traditional programming environment, make a dumb data object for the record (more…)

54.

Replace Subclass with Fields
If you have subclasses that vary only in methods that return constant data, change the methods to superclass fields and eliminate the subclasses (more…)

55.

Replace Type Code with Class
If a class has a numeric type code that does not affect its behavior, replace the number with a new class (more…)

56.

Replace Type Code with State/Strategy
If you have a type code that affects the behavior of a class, but you cannot use subclassing, replace the type code with a state object (more…)

57.

Replace Type Code with Subclasses
If you have an immutable type code that affects the behavior of a class, replace the type code with subclasses (more…)

58.

Introduce Explaining Variable
If you have a complicated expression, put the result of the expression, or parts of the expression, in a temporary variable with a name that explains the purpose (more…)

59.

Remove Assignments to Parameters
If the code assigns to a parameter, use a temporary variable instead (more…)

60.

Self Encapsulate Field
If you are accessing a field directly, but the coupling to the field is becoming awkward, create getting and setting methods for the field and use only those to access the field (more…)

Big Refactorings

The Top 10 Problems with IT Certification in 2008

Since the early part of this decade, when I wrote several certification articles for InformIT, IT certifications have changed a great deal, and the industry’s perception of certifications has waned. IT certifications have fallen out of favor in the eyes of many.

Less than 10 years ago, I had no reservation about recommending a certification to a person interested in entering the IT sector. Certification and the training needed to “earn” an IT certification was a great way for a career changer, a displaced worker, or someone simply looking for a career to get a foot in the door on a growing field and land a good job with a lot of growth potential.

Certification no longer guarantees that you will be able to find that kind of job in IT. It still has its place, but the IT certification industry has faced some systemic problems that no one has addressed since its emergence.

Having jumped hook, line, and sinker into the certification world in 1995, I have a bit of historical perspective about where we have been and where we are and what the problems are.

The following are the topics I want to cover during the course of three articles:

• In this first article, I’ll examine the top 10 problems with IT certification in 2007–2008.
• Next, I’ll re-examine the first steps you should consider if you want to enter IT using the current certification paths.
• In the third article, I’ll present to InformIT readers an integrated networking program as a possible solution to the current problems with IT certification.

But before we can fix the problems, we have to define those problems. On to the problems.

1. Certifications are Vendor-centric

IT certifications, as they are currently marketed, are vendor-centric. Their purpose is to quantify a person’s understanding of some of the functionality of a vendor’s product.

A vendor’s certification helps a potential client feel a sense of ownership when it comes to a product. Those who support a vendor’s IT products are encouraged to certify in the product(s) to validate their skill levels.

The problem is that every vendor has its own set of certification criteria; none of them match, and there is no uniformity. Whatever Vendor A says you should know is what you need to know in order to achieve validation.

If you have ever taken a Novell exam, a Microsoft exam, a Cisco exam, and/or a CompTIA exam, you probably have been told to answer the questions on the exam the way the given vendor wants you to answer the questions.

Don’t worry if the answer is ridiculous; if you want to get certified, give the Novell answer, or the Microsoft answer, or the Cisco answer, or the CompTIA answer. For the same question, each vendor could potentially have different correct responses. This is maddening at best.

2. Certification’s Life Cycle Is Short!

Because IT certifications are vendor-centric, a vendor can revise, revamp, or completely redo a certification as often as it wants. Much is based on the life cycle of a given product, such as an operating system. If you want to feel like you are simply chasing your tail, keep up your certifications based on a vendor’s whim and whimsy for how long they feel a product’s life cycle is.

Here’s a good example from my experience. In 1995–1996, I earned the Microsoft MCSE for NT 3.51 through a lot of hard work. Not six months later, however, Microsoft changed the MCSE requirements for the MCSE in NT 4.0. The seven exams I took for 3.51 no longer had legs. I had to take six or seven more. So I did.

Well, guess what happened in 1999–2000? Windows 2000 came out, along with a whole new series of exams—which almost killed me. Now in less than 4 years I had taken close to 21 exams to earn 3 Microsoft certifications that I needed to teach the most up-to-date Microsoft classes. Several years later, Windows 2003 came out with two more upgrade exams, which so far I have not taken/passed because of disgust with the process. I will probably have to take them before long because the Longhorn roadmap “encourages” MCSEs to be at least 2003 to avoid taking all exams again.

Now a sane person would say that I did not have to be MCSE-2003 if I did not have to teach those classes. I have supported Windows Server 2003 since it was in beta without a MCSE-2003 and never had a problem.

I would agree until recently, when I was talking to an HR recruiter who told me that a company that was interested in me would not consider any of my experience unless I had the latest-and-greatest MCSE. Three earlier MCSEs and 15 years of field experience made no difference. If I did not have the MCSE 2003 they would look elsewhere.

Guess what? They looked elsewhere.

3. Certifications Are Not Real-World Oriented

Because certifications are vendor-oriented, they do not prepare you for the real world. Every vendor would have you believe that every enterprise environment is made up of only their platform or application. In today’s market nothing is farther from the truth. Every environment is integrated.

No environment is made up of just Microsoft, or UNIX, or Novell, or Linux. The real-world enterprise is made up of at least two platforms, and tens if not hundreds of applications from a host of vendors. The real world is a fully integrated environment. If you are focused on one vendor’s platform/application, could you in practice manage a real-world enterprise comprised of numerous platforms, or do you have to outsource what you don’t know—thereby giving up ownership to someone else?

If you earn the MCSE from Microsoft, are you qualified to administer a Lotus Notes environment or a Cisco environment? If you are a certified Linux admin, are you qualified to manage a Windows 2003 environment running SQL 2005?

4. Certifications Have Been Devalued

This next problem is no secret. IT certifications have been devalued since their heyday in the mid- to late 1990s. The reasons for the devaluation could be the basis for a book. Some of the major reasons why many in the industry do not respect IT certs are the following:

• Brain dumps let you get all the questions on a live exam. You can then pass the exam without knowing the technology.
• Paper certs: those who have used brain dumps or so-called study guides that many sites sell to prep a person for the live test questions. People earn the certification without training and without experience, and advertise themselves as experts. This makes everyone look bad and devalues the certification process.
• Testing issues are legendary. There are some vendors, such as Microsoft and Cisco, which are trying to improve the value of the testing experience by incorporating simulations. But in my opinion it is a band-aid. Knowledge-based cognitive exams are awful. Many are poorly written, poorly edited, not real-world oriented, and not in tune with the needs of the industry.
• It is difficult to truly accept whether candidates know their stuff based on these exams. If you pay enough, a trained chimp could pass many of these exams.
• Practicums, which in my opinion are the best testing methodology currently available, are not widely used. When a practicum is done right, knowledge and experience are absolutely needed. Brain dumps are useless. What matters is skill.
• In short, testing has been inconsistent and all over the map devaluing certification.

5. No Oversight Body

Because certifications are vendor-centric, no one is overseeing the whole process.

Can we please stop fighting FUD with FUD?

By Ryan Cartwright

Online on: 2008-02-12

It has long been the case that proprietary software companies
regularly engage in FUD (fear, uncertainty and doubt) tactics against
their opponents. This particularly seems to apply to Microsoft’s
statements about free software in general and GNU/Linux in particular.
Recently I’ve noticed a surge in the amount of FUD going the other
way—from the FOSS community towards Microsoft and other proprietary
software companies. Why do we feel it is necessary to fight FUD with
FUD
The genesis of FUD

According to Wikipedia FUD has been used in various contexts since the
1920s but became more used as a terminology in the 1980s and 1990s. It
is most frequently associated with Microsoft. Of course, they are not
the only proponents of FUD but they do seem to employ it a fair bit.

I am not a fan of Microsoft or their monopolistic marketing tactics

FUD from the FOSS community is, again, not new but in recent years it
has become a more widespread tactic—particularly where Microsoft is
the target. Just so I don’t give the wrong idea: I am not a fan of
Microsoft or their monopolistic marketing tactics. I just don’t think
the FOSS community should be so ready to use those same tactics as a
defence. So what are the examples of FOSS FUD then? I don’t want to
make this into a rant against any individual so I won’t give explicit
examples but below are the kinds of arguments you might find in FOSS
FUD.
FOSS FUD

* “Using FOSS will save you thousands!”
* “Microsoft’s products suck”
* “If you are not using 100% free software—don’t bother”

That list in not exhaustive but why would I consider this FUD? To be
honest—it’s not the statements themselves as the way they are
presented. What bothers me is when the “facts” are twisted or poorly
researched. All it does is make us look at best foolish and at worst
dishonest. When you compare the retail cost of the most expensive
proprietary product ranges it is a comparison most people won’t
recognise. In the proprietary world bulk-discounts, student editions,
special offers abound. Rarely do people pay the full retail price. In
any case I’ve said before that cost is not the best argument to
use—particularly as others have mentioned you may not always be the
cheapest. Using cost may get people’s attention but it won’t last if
your ‘facts’ are biased—even with the best of intentions.

If you’re to going run down Microsoft products then you need to be
specific. What products suck, why and how do they suck? I see a lot of
this type of thing that simply shows the proponent has rarely used the
product in question. Aside from that, is this really a good argument
to make? Are we really going to be so arrogant as to imply that free
software doesn’t suck at all? By running down the opposition aren’t we
implying there are no issues with “our” software? Arguing your case by
running down the opposition is the stuff of politicians and is pure
FUD. Argue your case on the merits of free software not the faults of
the proprietary alternatives. There are situations when it is useful
to highlight the differences there’s a very real danger of it sounding
bitter and jealous.

With regards the purist argument: I agree that the world would be
better if everyone used entirely free software—something I try to do
myself. That said, if you come in too quick and aggressive with this
point you can drive people away just as they are starting to take an
interest. We need to encourage people to take small steps into our
brave new world. Let’s allow people to open their eyes at their own
pace.
Swapping shoes

Before we make any plug for free software, we would do well to put
ourselves in the other person’s shoes. What may sound obvious to us
could sound bitter, pedantic or jealous to them. It’s difficult to do
this though and we’ll always come to that point where mis-information
needs correcting. This is when we need to consider how they may
interpret what we say or write.

If we want to promote free software—and it’s associated ideals—to
new
users then we should promote it on its merits, without twisting facts
and by giving them a chance to get it wrong occasionally. Most Windows
users I know moan about it. They tell me it’s ‘bad’ without me having
to tell them. My job therefore becomes simpler: to tell them how they
will benefit from free software.
FUD is FUD is FUD

Fighting FUD with FUD will nearly always leave the listener/reader
confused and less enthusiastic about your side. I—for one—would
like
to see more blogs and comments on why free software is good rather
than why Microsoft is bad. So let’s start here. Your task is complete  the sentence “Free software is good because…” in less than 50 words.

Summary
Debate sprang up at JAOO ’07 around Bob Martin’s assertion that
“nowadays it is irresponsible for a developer to ship a line of code
he has not executed in a unit test.” In this InfoQ video, he debated
with Jim Coplien on this and other topics, including Design by
Contract vs. TDD and how much up-front architecture is needed to keep
a system consistent with the business domain model.

Bio
Bob Martin is an Agile Manifesto author, and author of books on Agile
Programming, XP, UML, O-O Programming, and C++. He is CEO and
president of Object Mentor www.objectmentor. com/ Jim Coplien is a
software pioneer in o-o programming and C++ and multi-paradigm design.
He appreciates the human side of design, and has written critically
acclaimed books on design and development.

Excerpts:

B: So I have 3 laws of test driven development. The first one is: a
test driven developer does not write a line of production code until
he has written a failing unit test, and no production code can be
written until there is a failing unit test…

J: Per se, the main concerns I have about TDD are not problematic with
respect to what you’ve just said in isolation, so if it’s no more and
no less than that we may not have a big disagreement. What my concern
is, then, comes out of doing broad work with a lot of clients and a
little bit of interactions with other consultants and other scrum
masters who have seen these things happening in their project. And
we’ve seen 2 major problems: one is that use of TDD without some kind
of architecture or framework into which you’re working – which was
very strongly Kent’s original position: you use TDD to drive your
architecture – leads to a procedural bottom-up architecture because
the things you are testing are units.

We just had a discussion upstairs about “is TDD the same as unit
testing?” Well, no, it’s a little more, but unit testing was a great
idea in Fortran, when you could build these layers of APIs and the
units of organization of the software were the same as the units of
testing, but today the units of organization of the software are
objects and we’re testing procedures and there is a little bit of a
mismatch. Now, if you are using the procedures to drive your
architecture, I think you are trying to build a 3 dimensional
structure from 2 dimensional data, and you end up going awry. And one
of the things we see a lot, in a lot of projects, is that projects go
south on about their 3rd sprint and they crash and burn because they
cannot go any further, because they have cornered themselves
architecturally. And you can’t refactor your way out of this because
the refactoring has to be across class categories, across class
hierarchies, and you no longer can have any assurances about having
the same functionality.

The other problem we’ve seen is that this destroys the GUI and this is
what Trygve [Reenskaug] and I talk a lot about, because you have this
procedural architecture kind-of in a JAVA class wrapper; you no longer
are driving the structure according to domain knowledge and things
that are in the user’s conceptual model of the world, which is where
object orientation came from. I mean even Kent, as he’s very often
said: “you can’t hide a bad architecture with a good GUI.” The
architecture will always shine through to the interface, and I
strongly believe that, and that is why I believe we need something in
the infrastructure that gives you a picture of what the domain model
is out at the interface. Then, if I want to apply Uncle Bob’s 3 rules
I probably don’t have a problem with that, but I want a starting place
that captures this other dimension, which is the structural dimension.

B: Alright. But you do not accept the thesis that the practice of test
driven development is a pure requisite to professional behavior in
2007.

J: I absolutely do not accept that.

——————————-

http://www.useit.com/alertbox/application-mistakes.html

Jakob Nielsen‘s Alertbox, February 19, 2008:

Top-10 Application-Design Mistakes

Summary:
Application usability is enhanced when users know how to operate the UI and it guides them through the workflow. Violating common guidelines prevents both.

It’s hard to write a general article about application design mistakes because the very worst mistakes are domain-specific and idiosyncratic. Usually, applications fail because they (a) solve the wrong problem, (b) have the wrong features for the right problem, or (c) make the right features too complicated for users to understand.

Any of these three mistakes will doom your app, and yet I still can’t tell you what to do. What’s the right problem? What are the right features? What complicating curlicues can safely be cut from those features? For each domain and user category, these questions have specific and very different answers.

The only generalizable advice is this: rather than rely on your own best guesses, base your decisions on user research:

• Conduct field studies and task analysis before deciding what your app should do.
• Paper prototype your initial ideas before doing any detailed design — and definitely before wasting resources implementing something you’d have to change as soon as you get user feedback.
• Design iteratively, conducting many rounds of quick user testing as you refine your features.

Of course, people don’t want to hear me say that they need to test their UI. And they definitely don’t want to hear that they have to actually move their precious butts to a customer location to watch real people do the work the application is supposed to support.The general idea seems to be that real programmers can’t be let out of their cages. My view is just the opposite: no one should be allowed to work on an application unless they’ve spent a day observing a few end users.

(Whatever you do, at least promise me this: Don’t just implement feature requests from “user representatives” or “business analysts.” The most common way to get usability wrong is to listen to what users say rather than actually watching what they do. Requirement specifications are always wrong. You must prototype the requirements quickly and show users something concrete to find out what they really need.)

All that said, there are still plenty of general guidelines for application UIs — so many, in fact, that we have a hard time cramming the most important into our two-day course. Here’s my list of 10 usability violations that are both particularly egregious and often seen in a wide variety of applications.

1. Non-Standard GUI Controls

Basic GUI widgets — command links and buttons, radio buttons and checkboxes, scrollbars, close boxes, and so on — are the lexical units that form dialog design’s vocabulary. If you change the appearance or behavior of these units, it’s like suddenly injecting foreign words into a natural-language communication. Det vil gøre læserne forvirrede (or, to revert to English: Doing so will confuse readers). For some reason, homemade design’s most common victims are scrollbars. For years, we’ve encountered non-standard scrollbars in our studies, and they almost always cause users to overlook some of their options. We’re seeing this again this year, in the studies we’re conducting to update our course on Fundamental Guidelines for Web Usability. (The linked article includes screenshots of offending scroll controls.)

Some of the world’s best interaction designers have refined the standard look-and-feel of GUI controls over 30 years, supported by thousands of user-testing hours. It’s unlikely that you’ll invent a better button over the weekend.

But even if your homemade design, seen in isolation, were hypothetically better than the standard, it’s never seen in isolation in the real world. Your dialog controls will be used by people with years of experience operating standard GUIs.

If Jakob’s Law is “users spend most of their time on other websites,” then Jakob’s Second Law is even more critical: “Users have several thousand times more experience with standard GUI controls than with any individual new design.”

Users will most likely fail if you deviate from expectations on something as basic as the controls to operate a UI. And, even if they don’t fail, they’ll expend substantial brainpower trying to operate something that shouldn’t require a second thought. Users’ cognitive resources are better spent understanding how your application’s features can help them achieve their goals.

1.a. Looking Like a GUI Control Without Being One

The opposite problem — having something that looks like a GUI control when it isn’t one — can reduce usability even more. We often see text and headlines that look like links (by being colored or underlined, for example) but aren’t clickable. When users click these look-alikes and nothing happens, they think the site is broken. (So please comply with guidelines for visualizing links.) A similar problem occurs when something looks like a button but doesn’t initiate an action, or looks like a radio button but isn’t a choice. We found an example of this in our current round of studies.

To design a custom-tailored shirt on Liste Rouge Paris, you must provide your measurements. As the following screenshot shows, there are two different paths through the application here, depending on whether your measurements are already on file with the tailor.

Our test user clicked incessantly on the New Customer button to indicate that he was indeed a new customer. Unfortunately, this screen element was not a button at all, but rather a non-clickable heading.

He was the only user to test this site because he encountered it during a task in which users could choose a site to visit (usually from a search listing). In this case, the user eventually overcame the confusion and proceeded to enter his measurements. If we had tested more users, a small percentage would have likely failed at this point. Each small error in dialog design reduces usage only by a small amount, but most UIs contain bundles of errors, and the number of lost customers adds up.

As an aside, this screen also uses radio buttons incorrectly. In theory, all five choices are mutually exclusive, which does call for radio buttons. But in the user’s mental model of the workflow, there are actually two issues here: (a) new vs. old customers, and (b) how to provide the measurements for your situation. You should use a single set of radio buttons only when users will choose between options for a single issue.

So, in the case above, a better design would first ask users to decide the new/existing customer question, and then reveal the relevant radio buttons for the option they choose.

2. Inconsistency

Non-standard GUI controls are a special case of the general problem of inconsistent design.Confusion results when applications use different words or commands for the same thing, or when they use the same word for multiple concepts in different parts of the application. Similarly, users are confused when things move around, violating display inertia.

Using the same name for the same thing in the same place makes things easy.

Remember the double-D rule: differences are difficult.

Another example from our current study: Expedia pops up a two-month calendar view when users specify the departure or return date for a trip. The composite screenshot below was taken in February and shows what happens when you want to book a trip that starts on March 10 and ends on March 15.

In the second pop-up, the month of March has moved to the left, leaving room for April to appear on the right. This may seem like a convenient shortcut, since there’s no way the user would want a February return date when traveling out in March.

In reality, however, the user is looking for March 15 in the same spot where it appeared in the first pop-up calendar: in the right-most column.

In our testing, the inconsistent placement of the months in the second pop-up caused confusion and delays, but users ultimately figured it out. We tested only a few users with this site, but if you observe this kind of almost-miss error in user testing, it’s usually a sign that a few users will make the mistake for real during actual use.

Booking the wrong return date can have disastrous consequences — customers could arrive at the airport without a ticket for their expected flight. If a site has good confirmation emails, users might discover the problem before departure, but even that will cause aggravation and expensive customer support calls to resolve the situation.

Even if people eventually use the calendar correctly, it takes more time to ponder the inconsistent design than the time users save by not having to click the next-month button for April departures.

The shortcut that moves the months around saves time only for very frequent users who learn how to efficiently operate this part of the UI. So, an application for professional travel agents should probably use Expedia’s calendar design. A site targeting average consumers should not.

3. No Perceived Affordance

“Affordance” means what you can do to an object. For example, a checkbox affords turning on and off, and a slider affords moving up or down. “Perceived affordances” are actions you understand just by looking at the object, before you start using it (or feeling it, if it’s a physical device rather than an on-screen UI element). All of this is discussed in Don Norman’s book The Design of Everyday Things. Perceived affordances are especially important in UI design, because all screen pixels afford clicking — even though nothing usually happens if you click. There are so many visible things on a computer screen that users don’t have time for a mine sweeping game, clicking around hoping to find something actionable. (Exception: small children sometimes like to explore screens by clicking around.)

Drag-and-drop designs are often the worst offenders when it’s not apparent that something can be dragged or where something can be dropped. (Or what will happen if you do drag or drop.) In contrast, simple checkboxes and command buttons usually make it painfully obvious what you can click.

Common symptoms of the lack of perceived affordances are:

• Users say, “What do I do here?”
• Users don’t go near a feature that would help them.
• A profusion of screen text tries to overcome these two problems. (Even worse are verbose, multi-stage instructions that disappear after you perform the first of several actions.)

When I tested some of the first Macintosh applications in the mid-1980s, users were often stumped by the empty screen that appeared when they launched, say, MacWrite. What do I do here, indeed. The first step was supposed to be to create a new document, but that command was not shown anywhere in the otherwise highly visible Macintosh UI unless you happened to pull down the File menu. Later application releases opened up with a blank document on the screen, complete with an inviting, blinking insertion point that provided the perceived affordance for “start typing.”

3.a. Tiny Click Targets

An associated problem here is click targets that are so small that users miss and click outside the active area. Even if they originally perceived the associated affordance correctly, users often change their mind and start believing that something isn’t actionable because they think they clicked it and nothing happened. (Small click zones are a particular problem for old users and users with motor skill disabilities.)

4. No Feedback

One of the most basic guidelines for improving a dialog’s usability is to provide feedback:

• Show users the system’s current state.
• Tell users how their commands have been interpreted.
• Tell users what’s happening.

Sites that keep quiet leave users guessing. Often, they guess wrong. (For an example of the problems with poor feedback, see the screenshot of VW’s car configurator toward the bottom of my recent article reporting on our current round of testing: Because users couldn’t tell which tire was selected, they had trouble designing their preferred car.)

4.a. Out to Lunch Without a Progress Indicator

A variant on lack of feedback is when a system fails to notify users that it’s taking a long time to complete an action. Users often think that the application is broken, or they start clicking on new actions. If you can’t meet the recommended response time limits, say so, and keep users informed about what’s going on:

• If a command takes more than 1 second, show the “busy” cursor. This tells users to hold their horses and not click on anything else until the normal cursor returns.
• If a command takes more than 10 seconds, put up an explicit progress bar, preferably as a percent-done indicator (unless you truly can’t predict how much work is left until the operation is done).

5. Bad Error Messages

Error messages are a special form of feedback: they tell users that something has gone wrong. We’ve known the guidelines for error messages for almost 30 years, and yet many applications still violate them. The most common guideline violation is when an error message simply says something is wrong, without explaining why and how the user can fix the problem. Such messages leave users stranded.

Informative error messages not only help users fix their current problems, they can also serve as a teachable moment. Typically, users won’t invest time in reading and learning about features, but they will spend the time to understand an error situation if you explain it clearly, because they want to overcome the error.

On the Web, there’s a second common problem with error messages: people overlook them on most Web pages because they’re buried in masses of junk. Obviously, having simpler pages is one way to alleviate this problem, but it’s also necessary to make error messages more prominent in Web-based UIs.

6. Asking for the Same Info Twice

Users shouldn’t have to enter the same information more than once. After all, computers are pretty good at remembering data. The only reason users have to repeat themselves is because programmers get lazy and don’t transfer the answers from one part of the app to another.

7. No Default Values

Defaults help users in many ways. Most importantly, defaults can:

• speed up the interaction by freeing users from having to specify a value if the default is acceptable;
• teach, by example, the type of answer that is appropriate for the question; and
• direct novice users toward a safe or common outcome, by letting them accept the default if they don’t know what else to do.

Because I used Liste Rouge Paris as a bad example under Mistake #1a, I thought I’d play nice and use them as a good example here. The tailor offers 15 different collar styles (among many other options) for people ordering custom-designed shirts. Luckily, they also provide good defaults for each of the many choices. In testing, this proved helpful to our first-time user, because the defaults steered him toward the most common or appropriate options when he didn’t have a particular preference.

Dialog to specify your shirt’s collar on www.listerouge-paris.com (3 of 15 styles shown).

8. Dumping Users into the App

Most Web-based applications are ephemeral applications that users encounter as a by-product of their surfing. Even if users deliberately seek out a new app, they often approach it without a conceptual model of how it works. People don’t know the workflow or the steps, they don’t know the expected outcome, and they don’t know the basic concepts that they’ll be manipulating.For traditional applications, this is less of a problem. Even if someone has never used PowerPoint, they’ve probably seen a slide presentation. Thus, a new PowerPoint user will typically have at least a bare-bones understanding of the application before double-clicking the icon for the first time.

For mission-critical applications, you can often assume that most users have tried the app many times before. You can also often assume that new users will get some training before seeing the UI on their own. At the minimum, they’ll usually have nearby colleagues who can give them a few pointers on the basics. And a good boss will give new hires some background info as to why they’re being asked to use the application and what they’re supposed to accomplish with it.

Sadly, none of these aides to understanding apply for most Web-based applications. They don’t even apply for many ephemeral intranet applications.

Usability suffers when users are dumped directly into an application’s guts without any set-up to give them an idea of what’s going to happen. Unfortunately, most users won’t read a lot of upfront instructions, so you might have to offer them in a short bulleted list or through a single image that lets them grok the application’s main point in one view.

As an example, our test user who was trying to order a custom-tailored shirt was highly confused when the first screen in Hamilton Shirts’ “Create Your Shirt” process displayed a fully designed shirt with an “Add to Bag” button. This screen mixed two metaphors: a configurator and an e-commerce product screen.

This is a case where a default value isn’t helpful: people who want to design their own shirt are unlikely to want to buy a pre-designed shirt on the first screen.

(This screen also suffers from Mistake #1: non-standard GUI controls. In addition to its non-standard drop-down selection menus in a tabbed dialog that doesn’t look enough like tabs, the screen has a non-standard way of paging through additional fabric swatches. Users are less likely to understand how to select fabrics when the controls are presented in this manner.)

Our test user never understood the process of designing his own shirt on this site and ultimately took his business elsewhere.

9. Not Indicating How Info Will Be Used

The worst instance of forcing users through a workflow without making the outcome clear is worth singling out as a separate mistake: Asking users to enter information without telling them what you’ll use it for.A classic example is the “nickname” field in the registration process for a bulletin board application. Many users don’t realize the nickname will be used to identify them in their postings for the rest of eternity — so they often enter something inappropriate.

As another example, we once tested an e-commerce site that smacked users with a demand for their ZIP code before they could view product pages. This was a big turn-off and many users left the site due to privacy concerns. People hate snoopy sites. An alternative design worked much better: It explained that the site needed to know the user’s location so it could state shipping charges for the very heavy products in question.

10. System-Centric Features

Too many applications expose their dirty laundry, offering features that reflect the system’s internal view of the data rather than users’ understanding of the problem space.In our current study, one user wanted to reallocate her retirement savings among various investments offered by her company’s plan (for example, to invest more in bonds and less in stocks). She thought she did this correctly, but in fact she had changed only the allocation of future additions to her retirement account. Her existing investments remained unchanged.

As far as the mutual funds company is concerned, new investments and current investments are treated differently. Reallocating future additions means changing the funds they’ll buy when the employer transfers money into the account. Reallocating current investments means selling some of the holdings in existing mutual funds and using the proceeds to buy into other funds.

The key insights here?

• Our test user didn’t have this distinction between new and old money; she simply wanted her retirement savings allocated according to her revised investment strategy.
• Even users who understand the distinction between new and old money might prefer to treat their retirement savings as a single unit rather than make separate decisions (and issue separate commands) for the new and old money.

It would probably be better to offer a prominent feature for changing the entire account’s allocation, and use progressive disclosure to reveal expert settings for users who want to make the more detailed distinction between the two classes of money.

Bonus Mistake: Reset Button on Web Forms

This mistake relates to Web forms, but because so many applications are rich in forms, I’ll mention it here: It’s almost always wrong to have a Reset button on a Web form.The reset button clears the user’s entire input and returns the form to its pristine state. Users would want that only if they’re repeatedly completing the same form with completely different data, which almost never happens on websites. (Call center operators are a different matter.)

Making it easy for users to destroy their work in a single click violates one of the most basic usability principles, which is to respect and protect the user’s work at almost any cost. (That’s why you need confirmation dialogs for the most destructive actions.)