Wednesday, July 29, 2009
Friday, June 12, 2009
The Mr. Miyagi School of Software Engineering
This is a re-post from a journal entry I originally wrote over on Slashdot in 2004. I've made some minor changes and updates for this entry.
Background: This was an concept born out of necessity about 5 years ago. I needed a way to train someone with very little experience to work with Bridgeworks but I couldn't afford to spend hours and hours of my own time working with him; too many of my own responsibilities and deliverables. It was very successful and now he is our best Bridgeworks app developer. Fast-forward to today when I'm interviewing CS students from a local university for a summer internship. This is a (well) paid position for which I need someone with decent coding skills who is a self-starter. Unfortunately none of my candidates have any practical skills whatsoever. (I don't know what the universities are teaching, but it's not what we need in industry.) With these candidates it would be like starting from square one. Obviously I'm not going to pay what I'm willing to pay for people who don't have the quals. I am willing to train such a person as an unpaid intern, but that is not without its catches. I still don't have the time to spend hours and hours with these folks. Furthermore, ethically, unpaid internships are intended for the sole benefit of the student. My company should not benefit in any way from the labor of unpaid interns. Practically speaking, though, you can't train someone without giving them tasks. Re-enter the Mr. Miyagi School of Software Engineering.
Lessons on how to train a junior programmer:
Lessons on how to train a junior programmer:
Let's call him Danielsan.
Mr. Miyagi was a very wise and clever sensei. His methodology, loosely translated, is perfect for any small software company that is bringing new developers into the system. The reason Mr. Miyagi's method works so well is because it provides intense, immersive exposure to the most important lessons while demanding relatively few additional resources from the instructor(s). Think about it. While Danielsan was busy painting the fence and sanding the deck, Mr. Miyagi was out having the time of his life!
The length of each lesson is to be determined on a case by case basis.
Lesson 1: Write SDK Documentation
Even the best developers can be notorious for not adequately commenting their code. Good documentation of an software includes both programmer's notes and comments for automated documentation (e.g., doxygen). This oft neglected task is perfect for Danielsan. An excellent way for him to learn the software from a developer's perspective is to write the documentation that explains how it all works.
Listen carefully when Danielsan asks questions about the existing code base. Discourage him from asking too many questions, except regarding complex concepts. It is important that Danielsan develop his own understanding of algorithms, relationships, dependencies, etc.
Lesson 2: Build Company Demos
Documenting the code shows Danielsan how the software developer sees things. Danielsan also needs to see the software from users' perspectives. "Users" include programmers who develop applications from the software and end users of the applications that are developed. Ideally, these would be two separate lessons. Knowing that time and money are always issues, these lessons can be condensed into one by having Danielsan build the company demos.
Architects and senior engineers loathe building company demos. While they are often happy to write test apps for in-house use, company demos bring with them a mountain of maintenance headaches and customer support issues. Whether or not your company is big enough to have it's own department(s) for maintenance and support, it's worth putting Danielsan to work on company demos so he can get his hands a little dirty and see first hand the challenges facing maintenance and support team(s).
Lesson 3: Clean House
Many companies have coding standards that must be followed by all code writers. These standards help everyone to write clean, consistent code that everyone can understand. Unless you work at a sterlized laboratory, it's a safe bet that your house always needs cleaning. A great way for Danielsan to learn this important lesson and also develop habits that are consistent with the team is to set him to work checking for adherence to company coding standards, leaks, potential security issues and the like. It's also a convenient way for you to get your code checked by a fresh pair of eyes.
The Successful Sensei
The successful sensei will know that these lessons are not opportunities for him to relax his own standards or to set Danielsan to work unguided. The successful sensei practices what he preaches. He knows which lessons Danielson must learn on his own and which require guidance. Naturally, Danielsan may occasionally bemoan his instruction. Perhaps he will consider that his training is too rote or mundane. Since you can't just throw a bunch of karate maneuvers in his face to show him what he's learned, it's important to sometimes let Danielsan work on things he finds interesting and fun. Ask him to write stand-alone utility apps that your company might need. Give Danielsan isolated new tasks within the SDK, perhaps something that requires he work with others to design interface requirements, resource requirements, etc.
to be cont'd.
Axiom 1: Tooltips are better left on.
If you leave your tooltips on, chances are better that you will learn something new each time you use your application(s). For Danielsan, tooltips are especially useful when they instruct him about fundamental principles of programming, those that transcend applications.
Axiom 1a: Some tooltips are better than others.
Monday, May 18, 2009
On Ambient Visualization
I want visualization to be less a part of a specific application that I go to and to be more of a natural extension to the computer itself, available from everywhere. I want visualization to an ambient experience. When I encounter any table of data in any document container I'd like to be able to quickly view it as a column chart without starting up a chart-making or data processing application, without shuffling around through copy & paste. I just want to select rows and columns an pop a "window" with a chart in it in one easy step. If I can recognize with my eyes that a table contains place names or lat/lon pairs then a computer ought to be able to map it with minimal intervention on the part of the user. I should also be able to put my selected, obviously geospatial data on a virtual Earth model. With just a little more imagination I can see turning lists and tables into nodes and edges, viewable with graph layouts. Think Enso for visualization. I might want to do more than just look at my chart, map/Earth model, and graph. I might want to start to interact with these views (assume independently for now). It starts to seem like I need an application to do that, but I'm not ready to jump the gun. This is still in the realm of a capability and not necessarily an application. Applications start to assume containers and domain-specific use cases. Most visualization techniques have standard, "off-the-shelf" things you can do with them given basic commands or input devices. Charts can be sorted and transformed into different layouts. One can pan, zoom, and rotate maps and terrain. The technique of "drill-down" and "roll-up", which can be applied to any visualization technique, is nothing more than navigation of linked data at multiple levels of detail and sometimes across multiple view contexts. At what point do is a specialized application needed more than a capability? We may be overly conditioned to assume the application model when we think of software as having utility. This is changing rapidly on the web. (It was always thus on the Unix command line, yes?) Visualization ought to change with it. Leave the application building up to subject matter experts with an application domain, not to software programmers. Ah but wait, lest too much be read into a passing editorial remark. Obviously software programmers play a key role here. The tendency among programmers who attempt to answer that call is to build an "application building framework." Again, the assumption is that subject-matter experts always need an app to make use of viz. I wonder why visualization software shouldn't be a part of an operating system; a core capability for any application or purpose. There have been wonderful advances made through web browser extensions, but even here visualization is at best an after thought applied to a mostly universal application. (I say "mostly" b/c there are no less than 3 different web browsers installed on my one operating system.) What happens when someone emails me some data in a flat file that I open in a text editor? Instead what is need are document object models for visualization techniques and runtime software that can parse viz documents on the fly. The runtime is optimized for robust interaction and attribute manipulation of high level visual artifacts, not application-specific tasks. This runtime can be invoked from a background process or "embedded" (contained in, called from) an application runtime. Devices having different display and user interfaces can choose how to represent what are otherwise well understood visual metaphors. Data can be more easily passed around and visualized simply by passing text documents describing interactive, dynamically updatable (or not) views. (This seems inherently more secure, too.) Only this way is ambient visualization possible; something that is available everywhere on my computer, no matter what kind of computer/device/hardware platform I am using.
Monday, March 9, 2009
Sunday, February 15, 2009
Enterprise Architectures As Data 2
I wrote about this topic last December. Now I want to drill down on a key element of our approach for turning enterprise architecture models into queryable sources. Furthermore, I should address why anyone would ever care about "turning enterprise architecture...blah blah blah."
There is a technology aspect and a human aspect. Both are necessary, but technology alone is never sufficient. Far more important to our success has been a strategy focused on answering key stakeholder questions.
My experience is mostly with Department of Defense Architecture Framework (DoDAF), so I will use examples from that domain. But to the best of my ability I will use language that is portable to other domains.
So, what are "key stakeholder questions?" To what does "key" refer, "stakeholder" or "questions?" The answer to the second question is: both. The answer to the first question is: depends on which stakeholder(s) we are talking about.
In the Army, and DoD in general, organizations are broken down at the general officer level from 1-9 as follows:
- HR
- Intel
- Operations
- Logistics/Sustainment
- Planning/Doctrine
- IT
- Training
- Finance
- Civil-Military Cooperation
These are the key stakeholder perspectives at the highest level.
An Operator wants to know, "How will architecture help me win the fight (i.e., get the work done)?" A Budget Analyst wants to know, "How does architecture help me making smarter spending decisions?" These are reasonable questions.
UPDATE 2009-09-28: THERE IS AN ERROR IN THIS GRAPHIC. THE G8's perspective in this case is "Force Development." He is asking the question, "Is the Force we are developing in line with my capability expectations?"
Indeed, no model exists except to answer questions.
But when presented with architecture in forms that speak only to the IT/engineering perspective, i.e., schematics, flow diagrams and the like, the multi-stakeholder conclusion tends to be, "Architecture doesn't help answer my questions." That's unfortunate because architecture, especially at the scale and complexity of federal government, can be effective in answering many useful questions for all perspectives. The trick is to:
- Understand what questions are being asked from each perspective
- Extend architectures from models that produce schematics into queryable sources that can produce schematics and also answer questions
- Extract the answers to those questions automatically to an open, text-based format
- Transform answers into views that are "fit for purpose," i.e., can be understood and used from many perspectives
Therefore, the question IT people should be asking is, "What can I do to make architecture better able to answer stakeholder questions." To be sure, there are questions architectures can't answer. But it is more productive to focus on the questions that architecture can answer. Following are actual endpoints in use (though they don't point anywhere in this post):
Returns an Xml Node containing a NewDataSet for the distribution of platforms for the given architecture
Answers the question: What are the platforms of this architecture and how many of each?
Returns an Xml Node containing a NewDataSet for the distribution of platforms for the given architecture and TOE
Answers the question: What are the platforms of this architecture and TOE and how many of each?
Returns an Xml Node describing the equipment used by the given ONN in the given architecture
Answers the question: What equipment does this ONN use in this architecture?
Answers the question: What equipment does this ONN use in this architecture?
Believe it or not, this type of view can be automatically produced
from an enterprise architecture model
There is added value in this approach, too. From the technology side of the coin, opening up architecture models through relational databases and ubiquitous, text-based formats makes it much easier to relate architecture data with other data. An architecture can tell you "how many," but "how much" is probably in another database. In fact, there are about 85 software programs the Army knows about that are being used to track costs for systems. To be sure some will be eliminated. But many will stay and those that do must support data portability.
Ok, so...why does any of this matter?
Let us start with the fact that government is an enormous compiler of data. It really doesn't matter if we are talking about enterprise architecture, a Line Item Number database, a "portfolio management" system, or even good, old-fashioned spreadsheet. Analysts will never part with their spreadsheets. Wonks stuff data into tools.
Unfortunately, many useful tools that are good at capturing data are lousy at both storing it and saving it back out. Applications too often co-mingle their own data with the subject matter data, making it difficult to separate later. Many tools don't have export in mind. (All tools should have export in mind.) Owners of online, enterprise databases typically only offer their contents in human-readable formats; PDF and HTML pages. Applications built for one perspective are lousy at supporting other perspectives. The list of interoperability challenges goes on.
A battalion commander is not typically nimble with UML. Same goes for a budget analyst and resource director. In the world of enterprise architecture the consequence is that a lot of people are taking a lot of time away from their primary tasks so that they can manually shuffle data into views their many customers demand. Time is money. My back of the napkin estimate is that architecture shops are working twice as hard for half the output that they could otherwise achieve if they offloaded the ETLV problem to IT and got back to building architectures. Of course, plenty will point out that architecture and reality are often different. That's a topic for another discussion. Like it or not, enterprise architecture plays a huge role in government organizations, especially DoD. This is just about getting better return on that investment. It's opportunity for both a current cost savings and future "force multiplier."
Finally, I would argue that the strategy of answering key stakeholder questions is useful to knowledge management in general, regardless of subject matter domain or technology form factor.
Tuesday, January 27, 2009
"Response" to Previous
Update 12.28.09: I just had to record for posterity the flames from some folks who tagged my previous post in Reddit. (So much for polite, constructive discourse.) In truth, I would like to have this conversation with some of these folks. Even the harshest ones. But I don't want to have to register for a service I don't use and I don't want to get into flame wars over comment threads. I get the frustration. I've experienced it. I too have been and remain rather skeptical of the hype. Some level of hype gets things noticed and forces conversations that need to happen but aren't. Some of what I said was written and/or read poorly. For example, Mac/Office is about culture, not interoperability. I know that Google came before Web 2.0. That was expressed poorly. My company also was doing a lot of this stuff before we ever heard of Web 2.0. I can't speak for Tim O'Reilly, but I feel confident he realizes he didn't invent something. He made salient observations about the Internet and human behavior and how the two have, do, and perhaps ought to work together. Many of these concepts go back decades to the roots of computer science and the Internet. I've been in workshops with Senior Technical Fellows, having extremely well-qualified CVs, who said, "we proposed all this in the beginning." My response was, "Exactly. Isn't it past time we got back to that?"
And I know how radical ("insane") my idea sounds, but I am not saying government should fund Web 2.0. This is not about a bailout, as some seem to think. Some of these comments come from the position of having no idea how government runs. I'm saying government is actively spending money, money is being wasted, and I know from education and direct, relevant experience that several of the concepts articulated in the original essay can help tax paying citizens spend more wisely.
Consider this from the Army:
"The Army spends, under 85 programs, approximately $6.7B annually on Information Technology (I.T.) without a method to converge these systems into a centralized infrastructure designed to improve robustness and dynamically deliver web services to hundreds of thousands of users while reducing risk"
And that is just service within DoD, DoD just being one (the biggest) government spender on IT. It's full of waste and the reason isn't just because Web 2.0 is magic Koolaid or that we are already on to so-called Web 3.0. It is because the government still looks at the Web the way it used to be in the 90s; i.e., with a 1.0 mindset.
More concrete thoughts on this later on how exactly government might use Twitter, for example. Think SMS. Twitter is a metaphor. The folks who run Twitter - for example - just might be the Pros from Dover who can help save government from itself. Think FEMA and USAID...
Subscribe to:
Posts (Atom)
Kitchenfire 3 points 4 days ago[-]
I wonder if this guy knows that Macs can run MS Office. Or that he's insane.