Archive for the ‘by Steve’ Category
Don’t Do Me Like That
Monday, December 28th, 2009 by Scott HurlbertWhy more architectural layers = less toil (Part 1)
Thursday, November 12th, 2009 by Don RobinsIn our most recent Agile Enterprise JumpStart project, we built an application and collection of web services using the ASP.NET MVC Framework for one of our clients. Our decision and recommendation to use this particular technology was based on an early JumpStart Assessment that showed (contrary to the customer’s original beliefs) that the system requirements called for both a set of web services accessible from a Flash application running ActionScript, as well as an Administrative interface for the application’s relational data. The ASP.NET MVC framework, with its capability for serving up serialized JSON or XML data, as well as HTML views directly from a controller, was a perfect fit.
(more…)
Software engineering isn’t
Sunday, August 23rd, 2009 by Steve Bockman
There’s a long tradition (since 1968, according to Wikipedia) of looking at software development as an engineering discipline. But calling software development engineering is something like adhering to the letter of the law, rather than to the spirit.
Software development is about acquiring knowledge
If you think of software development as strictly an engineering discipline, you might be inclined to believe that the job of a software engineer is to apply his or her previous knowledge and training toward solving a particular problem. And you’d be right, to a point, because knowledge and training are important aspects of software development.
But you’d also be missing the key factor, that software development is mostly about acquiring new knowledge. Software developers are always engaged in the following pursuits:
- Discovering what to build
- Discovering how to build it
This goes a long way toward explaining why so much software is custom software. If software development were entirely an engineering discipline, it is conceivable that we would be able to construct just about any software application by plugging together the proper parts, chosen from a catalog of well-known, existing components. The fact that we aren’t even close to being able to do that is an indication that we still have a lot of discovery ahead.
I’m proud to be a member of the Outformations Agile Enterprise JumpStart team, a group of developers who regularly go beyond the engineering aspects of a problem, and who constantly engage in the important discovery processes that help insure that the right product gets built.
The Outformations Agile Enterprise JumpStart team is ready to assist you in your development efforts. We’ll take you beyond engineering, and help you discover what to build and how to build it, quickly and affordably. Visit the Outformations website to learn more about what Agile Enterprise Jumpstart can do for you.
Avoiding the knowledge transfer bottleneck
Tuesday, August 11th, 2009 by Steve Bockman
In software development there are many ways to transfer the knowledge about how to build a product to the people who do the actual building. Production can be severely hampered, however, if that knowledge is being produced more rapidly than it can be consumed. This is the knowledge transfer bottleneck.
I recently hosted a workshop that let participants experience three different ways of transferring knowlege in a production environment. The product, in this case, was a paper airplane of unusual design. The idea was to try different ways of transferring the knowledge about how to build the airplane from the “chief designer” (me) to the production workers, and to compare the relative productivity of the different methods, which were:
- Documentation - The workers were given written instructions (22 steps worth) for building the airplane.
- Reverse Engineering - The workers were given a completed airplane which they could study in order to reproduce the steps required to build it.
- Mentoring - The “chief designer” built an airplane step by step and the workers replicated each step as it was performed.
The experiment was conducted in two phases. In the first phase, all 8 participants used the Documentation method. In the second phase, one team of 4 tried Reverse Engineering, while the other team of 4 tried Mentoring.
The results were interesting. Using the Documentation method, only one person out of a total of 8 came close to being able to build the airplane at all in the 5-minute period allotted.
Using the Reverse Engineering method, 1 person out of a total of 4 produced a completed airplane in 5 minutes.
Using the Mentoring method, each of 4 team members produced a completed airplane, and in less than the 5 minutes available.
The knowledge transfer bottleneck in software
In a software development effort, knowledge transfer takes place all the time, and it’s easy to imagine a software developer in the “chief designer” role described in the exercise above.
Let’s say I’m a developer who has discovered, and written the code to implement, a technique for binding some data to the controls in a user interface, and that this technique forms a pattern that my fellow developers want to know about. If you were one of my fellow developers, would you rather I (a) gave you a document I had written about the technique, (b) told you where the code was and suggested you figure it out for yourself, or (c) paired with you to implement the pattern for a new set of data?
Now, certainly, pairing with you takes more of my time, and might seem less efficient from my viewpoint. After all, I could be off designing the next pattern, and the one after that. But the productivity of the team as a whole, rather than my personal productivity, is what’s important. And mentoring helps increase the team’s productivity by avoiding knowledge transfer bottlenecks.
Using Whiteboard Meeting Notes
Friday, April 10th, 2009 by David Chilcott
I really like taking pictures of a whiteboard during the meeting to keep a record of what’s been happening, but as you can see I let it get too far in front of me.
Now I’m feeling overwhelmed by the number of work related whiteboard photos I’m supposed to have organized/taken notes from.
