This is what software is written in. It requires years to fully master a language; some languages like C++ and Java have "parts" that can be mastered in less time. It is theorized that nobody knows how to use all of C++. Senior developers can become functional in a new language in a few months of study; new developers may take longer.
examples: C, C++, Java, C#, COBOL, perl, Python, RPG, Visual Basic
Scripting languages are generally simpler than full-blown languages, and take less time (but still signfiicant time!) to master. Senior developers can become functional in a scripting language in less than a day; new developers tackling their first scripting language may take a week.
examples: JavaScript, VBScript, Visual Basic for Applications, ASP
a framework is a "pre-coded application". You customize frameworks to build applications. It takes a long time to master a framework, but you can produce useable applications with very little study. Again, a senior developer may be able to do this in a month or so, and new developers may take longer. Frameworks vary widely in complexity, from J2EE and the MFC down to locally-built frameworks that may even be embedded in larger ones (e.g. a file export framework embedded in a J2EE application; Struts used in a J2EE application). Refer to individual framework names for detail.
examples: Microsoft Foundation Classes (MFC), J2EE, Struts
standard relational databases (RDBMS) use SQL as the basic query language; the differences between RDBMS's for programmers are small and quicky learned. Differences between versions are negligible (but see stored procedure languages, below). For database administrators, each database is unique; experience translates between database types, but generally not easily. There are differences between database engines; senior developers will know the quirks of each, but these things can generally be quickly learned unless very short term expertise is required.
examples: Oracle, SQL Server, Sybase, CA-Ingres, DB2, RDB, MySQL, Firebird
Here's where databases differ. If your customer asks for "Oracle", and doesn't ask for PL/SQL, any database experience may do (get clarification). But... if they ask for PL/SQL, that's specific to Oracle. Differences often occur from version to version of the database server.
examples: PL/SQL (Oracle), Transact-SQL (SQL Server)
Usually a J2EE deployment component. The app server interface is standard; developers who have used one have used them all, unless the client specifies use of the development environment that comes with the application server, or identifies non-standard features of the app server that should be considered. Be careful though: certain "application servers" are the core of a whole ERP application. This is a completely different beast, and requires a specialist. Also note that, like databases, app servers have quirks, and senior people will know about them.
examples of J2EE components: WebLogic, WebSphere, JRun, JBoss, Tomcat, Oracle Application Server
examples of ERP components: Oracle Application Server (different from above! so ask for clarification)
Libraries are usually specific to a programming language, and generally take a very short time to learn to use (there are exceptions). Interfaces are standard "views" on the libraries that implement them. If you know the interface, it doesn't matter whose version of the library you use, because the interface is standard. I have also placed some Java architectural components in this category because they're used in standard ways, just as libraries are, and they take about the same amount of time to learn.
| examples: | C++/Java: RogueWave |
| Java: JNDI, JNI, JAXP, JAXR, JCE, JDOM, log4j, SAX 2, JMX, JDMK |
This is the "desktop" where the developer works. Typically it takes less than a day to become functional in a given IDE, and mastering the IDE may take a long time, but the features used regularly don't take long at all. Compare this to Microsoft Word: you don't need or use all the functions that Word has to offer (and if you did, you'd likely become more efficient), but you learn them as you need them. You won't have any trouble moving to a new word-processing program, but you'd have to re-learn the specific features of Word that you use daily.
examples: DreamWeaver, JBuilder, Eclipse, SitePad, VisualAge, Visual C++/J++
Developers use a variety of tools as part of the infrastructure for getting things done, including build tools, source code control tools, compilers, debuggers, memory analyzers, test tools, and editors, as well as integrated tool sets (Development IDEs). Generally tools are used differently in each development organization, though this does not always hold true. Large, complex tools take a long time to master, but most developers can become functional with a tool in a day or less. If your client is looking for something specific (e.g. an expert at Mercury TestDirector or Perforce management or Rational RequistePro), that needs to be accounted for separately from general familiarity with the tools in use at that organization.
examples: Ant, ClearCase, CCS, RCS, Rational RequisitePro, Rational Rose, Perforce
Operating Systems form the "desktop" where everyone works. Technically, they bridge between the computer's hardware and the software that "runs on" the computer, but modern operating systems provide a lot more services than just that interface. It takes very little time to "learn" a modern operating system as a user, but it can take years and years of experience to get good at developing for one. When a client asks for expertise in a given operating system, ask them if they mean "using" or "exploiting". If they just mean "using", then you can minimize it in your list of requirements, because basic skills in any operating system can be learned in just an hour or two. If they mean "exploiting", then, well, look for solid experience.
examples: Windows 95/98/Me/XP/NT/2000, Solaris, Linux, AIX, HP-UX
Architectures & architectural patterns
Just like in a building, an architecture is the description, usually formal, of how the system is to be assembled. If you're an architect, it's extremely important to understand the architecture you're working under. There are broad classifications, such as J2EE and CORBA, naming both frameworks and the architecture the frameworks enforce, and there are less well-defined architectural categories, such as "n-tier". There are also architectural design patterns which, like arches and columns and screen walls, describe certain standard approaches to software architecture.
examples of architectures or defining architectural components: J2EE, CORBA, 2-, 3- and n-tier, client-server, web services
examples of architectural patterns: Model 2, MVC