tag:blogger.com,1999:blog-64620626271245194212024-03-13T09:20:14.673-07:00The Art in Business System DesignCommercial software system designers have a powerful influence on a large proportion of the population. This blog argues that every system, as well as their designers, have an overpowering social context as well. Mining this social context is the The Art in Business Systems Design.Jeff Chapmanhttp://www.blogger.com/profile/09414277588527738949noreply@blogger.comBlogger102125tag:blogger.com,1999:blog-6462062627124519421.post-58056438425877586612019-03-18T06:50:00.000-07:002019-03-18T07:00:52.792-07:00Artistic Tools<p><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_PRbkgMaKbFU/S8sHmySmHtI/AAAAAAAAADA/lhN_C5Fm5l0/s1600/Tools.JPG"><img style="float:right; margin:0 0 10px 10px;cursor:pointer; cursor:hand;width: 190px; height: 161px;" src="http://3.bp.blogspot.com/_PRbkgMaKbFU/S8sHmySmHtI/AAAAAAAAADA/lhN_C5Fm5l0/s320/Tools.JPG" border="0" alt=""id="BLOGGER_PHOTO_ID_5461467336033050322" /></a><br />How much of the nature of our software, its look and feel, the aesthetics, presentation, and capabilities, are determined by the nature of the tools that we use to create it? As developers, as artists creating works of interaction, data storage, and algorithms, isn't the result of our work as tied to our tools as a potter's works are tied to her clay and glazes? And hence we share pretty much the same neuroses with respect to our tools as any artist.<br /><br />With a few clicks of a mouse and by dragging some widgets here or there, we can create full application frameworks. Then once inside the code we press "dot" and select from a list of actions. So we love our tools because they allow us to do in one hour what used to take us a full day.<br /><br />At the same time however, if you want a highly animated presentation, then your tool might be ClearSlide. And if your application requires extensive analysis, dicing and slicing of multidimensional data, then your tools may include SQL and Cognos. And once you've chosen your tool and made your investment to learn its bells and whistles, woe be the time you need to develop something that your tool doesn't support.<br /><br />The tools that you use define you nearly as much as your accomplishments. True artists define a unique style by developing their own set of tools. A structure, a methodology, a bunch of accouterments seem to create themselves a priori out of thin air and then this drives the subsequent creating. When you are developing you should always strive to increase the variety of tools at your disposal, and leverage them by finding ways to blend them and make them work together.<br /><br /><br />Jeff Chapmanhttp://www.blogger.com/profile/09414277588527738949noreply@blogger.comtag:blogger.com,1999:blog-6462062627124519421.post-27171932016080907412019-02-19T06:26:00.000-08:002019-02-19T06:27:44.248-08:00The Art in Change<p><a href="http://2.bp.blogspot.com/_PRbkgMaKbFU/TK2_DtyQBzI/AAAAAAAAAHo/j-IXiVvX_gc/s1600/Change.jpg" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5525282388404340530" src="https://2.bp.blogspot.com/_PRbkgMaKbFU/TK2_DtyQBzI/AAAAAAAAAHo/j-IXiVvX_gc/s320/Change.jpg" style="cursor: hand; cursor: pointer; float: right; height: 148px; margin: 0 0 10px 10px; width: 166px;" /></a><br />In an <a href="https://artinbsd.blogspot.com/2016/09/artful-matchmaking.html">earlier post</a> I mentioned how a Business Analyst hooks up the creative talents with the business managers. Here we take a deeper look at the subtleties of this dynamic and reflect on the sociological influences that can determine its success.<br /><br />Discovery (or requirements solicitation) is the stage where this dynamic plays out. Partly it's a shuffling of who knows what, as well as all of the political dynamics of control, job security, opinion, and hidden agendas. All of these make cameo appearances during the process.<br /><br />Your role and title may indicate that you are simply writing a functional specification, but in actuality you are the director of a sublime process to keep the love and power flowing. To be able to effectively accomplish this you need both a mandate from a powerful source, as well as a higher set of guiding principles.<br /><br />When you run into resistance from people who already have a vested interest in the status quo, sometimes you will have to appeal your principles to them, and sometimes you will need to invoke the big stick of your higher power. Nevertheless, always keep firmly in your mind the old saying that fools take to themselves the respect given to their office. Serve humbly and walk away leaving the place a better place than how it was when you started.<br />
<br /></p>Jeff Chapmanhttp://www.blogger.com/profile/09414277588527738949noreply@blogger.comtag:blogger.com,1999:blog-6462062627124519421.post-81072765562879721712019-01-14T08:34:00.000-08:002019-01-14T08:34:57.093-08:00Artful Digression<p><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_PRbkgMaKbFU/TGPiY__ZnaI/AAAAAAAAAGU/GRZ5fa1q71U/s1600/Digression.JPG"><img style="float:right; margin:0 0 10px 10px;cursor:pointer; cursor:hand;width: 141px; height: 116px;" src="http://2.bp.blogspot.com/_PRbkgMaKbFU/TGPiY__ZnaI/AAAAAAAAAGU/GRZ5fa1q71U/s320/Digression.JPG" border="0" alt=""id="BLOGGER_PHOTO_ID_5504492088698969506" /></a><br />This blog is focused on the art and science of software development, but I don't want to imply that the contents herein represent a full picture of a programmers life. A great deal of outside experience ultimately influences your qualities as a software developer. This varies by person and personality, but for me the key outside activities for success are reading and walking.<br /><br />You should make an effort to discover various trade and technical magazines, even publications related to your specialty that you wouldn't otherwise consider visiting. You should make an effort to research the state-of-the-art in the business use of computers as well as strategic advancements happening in your industry and related industries. I also recommend a broad general reading background of a variety of magazines: you never know when a strange juxtaposition of unrelated ideas will lead to a new breakthrough.<br /><br />I can't overstate the value of walking. Not only does it clear your head of the clutter and confusions of political interests, the rhythm of your legs and the change of natural scenery will make you more aware of the proper balances in design. It will help you create a more naturalistic and organic path for your growth. Walk. Read.<br /></p><br /><p>Jeff Chapmanhttp://www.blogger.com/profile/09414277588527738949noreply@blogger.comtag:blogger.com,1999:blog-6462062627124519421.post-14904125430216384202018-12-14T07:28:00.000-08:002018-12-14T07:28:12.793-08:00The Art of the Job<p><a href="http://4.bp.blogspot.com/_PRbkgMaKbFU/TApQWLzLROI/AAAAAAAAAE4/3izPscCUyvs/s1600/job.jpg" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5479280238704411874" src="https://4.bp.blogspot.com/_PRbkgMaKbFU/TApQWLzLROI/AAAAAAAAAE4/3izPscCUyvs/s320/job.jpg" style="cursor: hand; cursor: pointer; float: right; height: 182px; margin: 0 0 10px 10px; width: 142px;" /></a><br />Every couple of years my mom asks "What exactly do you do?"<br /><br />Exactly? Well you see she only knows about computers from her laptop and the internet. So what does the job of being a software developer actually consist of? The easiest way to describe it (the work-work part of the job that is, aside from the social or sociological part of the job) is in terms of all of the steps involved in battling through a software project. This is the so-called SDLC, the software development lifecycle:<br /><br /><a href="http://artinbsd.blogspot.com/2011/06/artful-purchasing.html">Research</a> current and near-future relevant technology<br />Interview or focus sessions with clients<br />Develop implementation <a href="http://artinbsd.blogspot.com/2010/09/artful-choice.html">alternatives</a><br />Research vendors<br />Review alternatives with management<br />Develop a <a href="http://artinbsd.blogspot.com/2011/04/artistic-planning.html">project plan</a>Develop functional <a href="http://artinbsd.blogspot.com/search/label/Design">specifications</a><br />Design data flow and data structures<br />Develop design specifications<br />Design draft of <a href="http://artinbsd.blogspot.com/search/label/Screens">interface</a><br />Various programming tasks<br /><a href="http://artinbsd.blogspot.com/2010/02/artistic-test-harnesses.html">Unit test</a> programming<br />Software corrections from unit testing<br />System and stress testing Software<br />Corrections from system and stress testing<br />Alpha testing<br />Software corrections from alpha testing<br />Regression testing<br />Software corrections from regression testing<br />Technical <a href="http://artinbsd.blogspot.com/2010/01/artistic-documentation.html">documentation</a><br />Develop implementation plan<br />Develop training materials<br />Develop online help<br />Beta or parallel production testing<br />Training<br />Post implementation corrections<br />Production Support<br /><br />Well yeah, it's a lot of stuff, and it's what makes the job always interesting and challenging. <br />
<br /></p>Jeff Chapmanhttp://www.blogger.com/profile/09414277588527738949noreply@blogger.comtag:blogger.com,1999:blog-6462062627124519421.post-47767992862848074352018-10-12T09:25:00.000-07:002018-10-12T09:25:44.170-07:00Artistic Multitasking<p><br />Multithreading is a wonderful tool but you need to use it very carefully. First don't use it recklessly, as there are specific instances where it is of most benefit (see <a href="http://artinbsd.blogspot.com/2010/07/artistic-threads.html">this post</a> for examples). If you are not in a "cloud" environment that scales-out to add additional CPUs as required, then I have four tips to help you along your way.<br /><br />1. Tip 1 is to be sure to assign the Name property an each thread you start. This is really the only way to tell which thread caused exceptions and is the only clue when you're debugging of how you got here. Use a name relevant to the instigator method and the serial count of that particular thread.<br /><br />2. Think in terms of threads working on an instance of an object. This helps keep multiple threads from stepping on each others memory space. Put all the values for input into properties of your new object, create a method in that object that performs the "heavy lifting" and deep calculations, and then execute that method through the thread.Start (placing return values back into a property). As an added tip I like to build an array-list of all the objects I have actively submitted to threads; when the thread terminates I can pop its values out of the array and then null out its instance. <br /><br />3. If you anticipate that you may ever need the capability to abort the thread you are starting (for example if the user cancels the operation) it is far far better to make provisions for this within the thread, in the method you are executing, rather than using thread.Abort. I usually create a boolean property in my main class called panicStop. All threads check this value within each iteration of a for-loop, and bail out appropriately. <br /><br />4. Manage the quantity of threads you allow to run simultaneously. Beyond a certain threshold (depending on the number of CPUs on your box and other factors) firing more threads doesn't aid performance much. So manage it. <br /><br />Multithreading works great as long as you remember to use it for appropriate tasks, and pass each thread a new object to work on. Remember that you are flowing parallel, but in separate "streams", so as to avoid conflating the instance of each object.<br /></p><br /><p>Jeff Chapmanhttp://www.blogger.com/profile/09414277588527738949noreply@blogger.comtag:blogger.com,1999:blog-6462062627124519421.post-38811503136006214602018-09-18T08:26:00.000-07:002018-09-18T08:26:34.092-07:00Artful Minimalism<p><br />Nowadays you can buy development tools that incorporate tons of form-behind widgets and code generation that can produce web pages with pop-out scroll overs, call-outs, and just about every kind of special effect imaginable. Is all of this necessary? <br /><br />Unless you are building a data entry form (which has its <a href="http://artinbsd.blogspot.com/2011/08/art-of-form.html">own special challenges</a>) you are probably better off just to make sure your web pages meet a certain set of minimum requirements. After you have thrown together your page, run it through a few simple tests: <br /><br />1) Window Resizing <br />Open your page in a browser and resize the window to various heights and widths to see what happens. Did your layouts get mashed? Do you need to change column widths from fixed to a percentage? <br /><br />2) W3C compatibility <br />Submit your page to the free W3C verifier, just as a courtesy check to assure that your tags are all balanced and that your links are all valid. <br /><br />3) Powersave Mode <br />Fire up a browser on a smaller screen device and in the browser options turn off the setting that allows the web pages to "set their own colors." Also go into the properties tab on your desktop and change the color scheme to a power saving configurations, with a black background and white text. Now open up your web page to see what happened. Do you need to remove some "color" tags to keep it legible? <br /><br />4) Just The Facts <br />Go back into the browser settings and turn off automatic image loading. Refresh your web page. Does it still make sense with just the facts? Did you provide the necessary alt tags so that the user can still figure out where to click for navigation?<br /><br />Sure, spinning flashing widgets are fun to view on your site. For all of about ten seconds. What stays as important though is the actual informative content that you provide. Try to make it work under all conditions.<br /></p>
<br />Jeff Chapmanhttp://www.blogger.com/profile/09414277588527738949noreply@blogger.comtag:blogger.com,1999:blog-6462062627124519421.post-80347263677874895812018-08-14T07:17:00.000-07:002018-08-14T07:17:39.750-07:00Artful Influence<p><br />The art of software development can be much more than accomplishing projects. Often the successful path begins by focusing beyond the project at hand -- you need to review everything you can think of: personalities, creative ideas, political issues, hidden agendas, insecurities, technical questions, doubts about the future direction of technology, everything. <br /><br />You may find a need to be intensely aware of a <a href="http://artinbsd.blogspot.com/2010/09/artistic-meta.html">company's culture</a>. At other times it may appear that your real purpose is to change the culture, and your development project is just a means to achieve that end. You may also need to include a bit of an appraisal as to the strategic direction and positioning of your company: it might be wrong for you to try to turn your employer into the Nordstrom's of retailers if its intentions and strategy is to be the K-mart. <br /><br />In some consulting environments your purpose is not to accomplish anything. Your project is actually an anti-project, the staff is against you, and you succeed by making the staff accomplish their own agenda. You must use grace to provide a backflow, purposefully pointing away from their objectives. Occasionally you can be successful overall (and act in the best interest of your retainer) even though your own personal accomplishments and monthly status reports might lack a certain luster.<br /><br />Around one quarter of software design could be considered "art" in every sense of the word. Congruent to other creative arts a software designer encapsulates thought into both visual and written structures. Sometimes though the whole point of creating software is to go through the process of meeting with people and moving them from their preconceived positions to change the culture, nature, and very heart of your employer. So once in a while the parallels to art go deep down to its truer purpose: to move people's souls.<br /></p><br/><p>Jeff Chapmanhttp://www.blogger.com/profile/09414277588527738949noreply@blogger.comtag:blogger.com,1999:blog-6462062627124519421.post-75183131518927767112018-07-17T07:02:00.000-07:002018-07-17T07:02:32.210-07:00The Art in Value<p><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_PRbkgMaKbFU/TC9UnWvUQaI/AAAAAAAAAFU/BczULXOi8Wc/s1600/dollar.jpg"><img style="float:right; margin:0 0 10px 10px;cursor:pointer; cursor:hand;width: 133px; height: 149px;" src="http://3.bp.blogspot.com/_PRbkgMaKbFU/TC9UnWvUQaI/AAAAAAAAAFU/BczULXOi8Wc/s320/dollar.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5489699505883595170" /></a><br />One of the challenges in a creative profession is managing the perception of your “value” including the work that you perform, the objects that you create, and the temperament that you nourish. These are truly three independent metrics.<br /><br />Due to the demands of the profession and its continually advancing technologies developers tend to dwell more on what they already know (or what they need to learn) rather than focusing on how others perceive them. As software development is both an art and a vocation however, it is important to pay attention to both your internal qualifications as well as the perceived external value that you add to your job.<br /><br />The value of your physical software development opus is fourfold: it may provide a revenue stream by itself, it may tender “goodwill” to customers and draw them in to purchase other products, it may offer cost savings as the business operates, and finally it may give a strategic advantage by opening new markets that create unique services.<br /><br />The value of the product you help design is a separate matter however from the value of the actual work that you perform. Somewhat impishly, you can lead a project that creates the next YouTube and still only get paid like a system designer. Your employer compares your base salary to that of any other developer they could hire off the street. The cost of a foot of electrical wire inside a jet plane is the same even if you only use it to connect your power outlet to your reading lamp.<br /><br />But now let’s consider your actual value as viewed by your employer. This is a more nebulous quantity that relates to a host of factors, many of which are strictly outside of your vocation. Are you a healthy employee? Then you add value by your contributions to the company’s medical plan. Are you cheerful and easy to work with? Then you add value by improving the morale of the workplace. Are you a good mentor? Then you add value indirectly through improving the productivity of others.<br /><br />As a professional remember not only to stay sharp on your skills, but also to pay attention to the art in your value.<br /></p><br /><p>Jeff Chapmanhttp://www.blogger.com/profile/09414277588527738949noreply@blogger.comtag:blogger.com,1999:blog-6462062627124519421.post-73138887695659188922018-06-18T14:59:00.000-07:002018-06-18T14:59:52.371-07:00The Art of Humor<p><a href="http://4.bp.blogspot.com/_PRbkgMaKbFU/TCIDEElj7uI/AAAAAAAAAFM/gnE9DlyvAVY/s1600/laugh.jpg" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5485950664576331490" src="https://4.bp.blogspot.com/_PRbkgMaKbFU/TCIDEElj7uI/AAAAAAAAAFM/gnE9DlyvAVY/s320/laugh.jpg" style="cursor: hand; cursor: pointer; float: right; height: 143px; margin: 0 0 10px 10px; width: 150px;" /></a><br />
A friend consulting with me on an Data Warehouse development effort (<a href="http://www.dodiligencepartners.com/team_laniear.php">Lee Laniear</a>) once told me an excellent metaphor that explains the three types of software development projects.<br />
<br />
You are like an archer with a quiver full of arrows. In the first type of project, your user places the target in the distance, you grab and load your straightest arrow from your quiver, you draw back the bowstring, take aim, and you give it your best shot. The objective, of course, is to hit the bullseye. You may hit or you may miss, and certainly the aim is more difficult with increasing distance to the target or with increasing crosswinds. But the main point is that you can see where you want to go.<br />
<br />
In the second kind of project, you are still the archer, but the user runs back and forth fifty yards away carrying the target. The objective, of course, is to hit the bullseye (not the client). He may stop, run one way, then suddenly stop and run another. He may stand still for brief periods of time, and then without warning start running around again. You grab your straightest arrow from your quiver, you draw back the bowstring, and you aim where you think the target is going to be by the time your arrow reaches it. Your success depends to a great extent on your historical observations of how the user changes his mind. And your self-control to aim safely for the target and not allow your emotions to divert your attention toward more animated ends.<br />
<br />
In the third kind of project, you grab your straightest arrow from your quiver, you draw back the bowstring, and then leaning backward, you shoot your arrow straight up into the air. The object is to get the user, carrying the target on his head, to position himself directly underneath the falling arrow.<br />
<br />
Successful project managers have an ability to separate themselves from their immediate feelings about the folks providing them with work. They need to be able to understand a larger picture of how others view their world, have a sunny disposition, and cultivate a fair amount of self-effacing graceful humor.<br /></p>
<br />Jeff Chapmanhttp://www.blogger.com/profile/09414277588527738949noreply@blogger.comtag:blogger.com,1999:blog-6462062627124519421.post-10895334088629283272018-05-17T06:36:00.000-07:002018-05-17T06:36:00.777-07:00Artful Versions<p><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_PRbkgMaKbFU/TFgL23Ar_2I/AAAAAAAAAGM/6UXCppqV0Dk/s1600/versions.jpg"><img style="float:right; margin:0 0 10px 10px;cursor:pointer; cursor:hand;width: 195px; height: 141px;" src="http://1.bp.blogspot.com/_PRbkgMaKbFU/TFgL23Ar_2I/AAAAAAAAAGM/6UXCppqV0Dk/s320/versions.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5501159981940735842" /></a><br />When you focus on modular resilience, one item that helps a great deal is to pay attention to versioning. Version numbers are of use not only for change management but for testing and customer support as well. Apps developed with Microsoft tools keep their version numbers in a config file. You should standardize on a common meaning for the four subparts of version numbers.<br /><br />Upgrades that produce a system that is incompatible with a prior release should increment the "major" version number. Upgrades that retain compatibility but that add significant functionality, should upgrade the "minor" version number. Bug fixes that get packaged into a distribution should increment the "release" version number. Finally the developers should increment the fourth component, the "build" number, with every compilation.<br /><br />I like to present versions to the customer as major dot minor, for example this is versions 2.4 of the software. This version should display in a welcome pop-up and in the title bar of the main screen of your application. But for purpose of technical support I like to display (in a pop-up "About" box) something like version 2.4.3 build 118. Of course all of the version components are retrievable using the system reflection class.<br /><br />Another helpful trick is to include a parallel matching version number within the backing database. When the client begins to run your software, make sure the version number in the data is compatible with the number in your software.<br /><br />You should also version all of the modules within your software in a similar fashion. Although the component module versions aren't typically presented to the end user, reflect them to a called module (for debugging purposes) so that the called class can display the version of the invoker whenever it throws an error.<br /><br />Sometimes it may seem superfluous, but it only takes about 30 seconds to update a version number, and with multiple developers on a project you will find that having this tracking available is invaluable.<br /></p><br /><p>Jeff Chapmanhttp://www.blogger.com/profile/09414277588527738949noreply@blogger.comtag:blogger.com,1999:blog-6462062627124519421.post-71790662564343241492018-04-13T07:53:00.000-07:002018-04-13T07:53:08.572-07:00Artfully Clean<p><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_PRbkgMaKbFU/TSUcuroljcI/AAAAAAAAAIM/7z1p3Cq_XJQ/s1600/Cleaning.gif"><img style="float:right; margin:0 0 10px 10px;cursor:pointer; cursor:hand;width: 234px; height: 202px;" src="http://3.bp.blogspot.com/_PRbkgMaKbFU/TSUcuroljcI/AAAAAAAAAIM/7z1p3Cq_XJQ/s320/Cleaning.gif" border="0" alt=""id="BLOGGER_PHOTO_ID_5558880903371263426" /></a><br />Imagine buying a house and then never doing the laundry, vacuuming, taking out the trash, or washing the dishes. You just let stuff pile up until you run out of space and then you throw your up hands and go “oh, it must be time for a new house.” Sounds ludicrous eh?<br /><br />In a highly competitive development environment though you build tables and files and directory folders, develop software, test a bit, and away you go. You patch up the bugs, optimize the queries, add a handful of indices, and you’re flying.<br /><br />After a couple years though people are wondering why things take so long. Unsurprisingly the typical reason is a failure to archive and then remove the old data. Nobody is taking out the trash! Data retention and archival policies never get baked into the original specifications as the sponsors seldom see any immediate competitive value from them. Eventually however a clean system becomes less of a luxury and more a necessity. Folks
start to notice the pile of dirty dishes.<br /><br />The effort required to retrofit for cleanliness is about the same as the effort for planning for this up front. Strictly operationally however it is better to delay this expenditure until a system becomes a mess as you will then have a better understanding of the corners with the most fuzzballs.<br /></p><br /></p>Jeff Chapmanhttp://www.blogger.com/profile/09414277588527738949noreply@blogger.comtag:blogger.com,1999:blog-6462062627124519421.post-42982501607324969492018-03-15T11:59:00.000-07:002018-03-15T11:59:30.690-07:00Artful Vendor Relations<p>
<br />In any business, nobody does all the work themselves. We all rely on outside vendors from such mundane chores as providing the toilet paper up through providing phone lines, tax services, and legal assistance. And here in Information Technology we have our own set of vendors with wonderfully peculiar characteristics.
<br />
<br />We group our unique compatriots into three worlds: the language vendors, the software package vendors, and the hardware vendors. We'll get to all three in due time, but today we will chat about the marvelous world of language vendors.
<br />
<br />Selecting a language vendor is a lot like choosing a wife. You may not have as much actual contact with the vendor as you would like, but you will get to deal with what she cooks up, and her aesthetic tastes will affect you long after she is gone. Yeah and changing language vendors is as painful as going through a divorce, but that's a story for another post.
<br />
<br />So what should you look for when selecting a language vendor? Probably the most important consideration is to perform an evaluation of their openness and how they admit to bugs and problems. Upgrades to language tools are major undertakings and a vendor doesn't take it lightly. So to meet ongoing challenges they should show resolve to provide workarounds.
<br />
<br />Languages and development tools constantly change (and I've never seen a version of a language released with fewer verbs than the previous version). To some extent, the vendor is trying to remain competitive by adding the functionality that becomes available in competitors' products or other languages. A software vendor employs a large number of programmers, who need to keep releasing new versions in order to maintain their livelihoods.
<br />
<br />So it turns out to be a bit of a balancing act managing your relationship with a language vendor: stability helps your programmers be productive, and yet staying current of tools allows you to incorporate new aesthetics and retain younger talent. If you happen to be in the position of selecting a vendor at the start of a large project you will partly need to use your intuition (and contacts in the industry) to get a better sense of the credibility of the press and of the vendors.
<br />
<br />On the other hand, if one of the major vendors announces their plans for their next release of one of their market-leading programming tools, then you would be remiss to overlook its pending availability in your plans. So take your time and be very deliberate when <a href="http://artinbsd.blogspot.com/2011/05/artistic-language.html">choosing a language vendor</a>, for you will be living with your choice for a long time.
<br /></p><br /><p>Jeff Chapmanhttp://www.blogger.com/profile/09414277588527738949noreply@blogger.comtag:blogger.com,1999:blog-6462062627124519421.post-90389461691731010302018-02-19T07:25:00.000-08:002018-02-19T07:25:55.184-08:00Artistic Sparsity<p><br />Even though we know it in our hearts, we still fail to account for how a software system grows and becomes more complex over time. Designing interface screens is a lot like planning an informal garden; if you want it to look great once all the plants take hold and fill out you need to think a bit about the future. Instead folks tend to wireframe a product that looks “complete” with reasonable use of the menu real-estate and a felicitous spread of field-density on the screen at the initial planting, as if the product is somehow “finished” once you implement it.<br /><br />In doing this we make things look good in the /present/, yet we fail to account for system growth. When we later add significant new functionality… surprise, our screens and menus appear too overgrown and cluttered. It’s as if you planted all the apple trees two yards apart because it looked better; now that they have branched and fruited they are all atop on another.<br /><br />Therefore when you are creating a new system plan for expansion by deliberately under-designing menus and occupancy: make the interface artistically sparse. And then don’t worry about it; like a garden your interface will “fill out” as it matures.<br /></p><br /><br />Jeff Chapmanhttp://www.blogger.com/profile/09414277588527738949noreply@blogger.comtag:blogger.com,1999:blog-6462062627124519421.post-18509817751140341702018-01-15T08:33:00.000-08:002018-01-15T08:33:59.349-08:00The Art in Modularity<p><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/-xDPoY0PjfiI/TZH8TRNTIjI/AAAAAAAAAJg/Hztgg_U_qlY/s1600/modular.jpg"><img style="float:right; margin:0 0 10px 10px;cursor:pointer; cursor:hand;width: 134px; height: 138px;" src="http://4.bp.blogspot.com/-xDPoY0PjfiI/TZH8TRNTIjI/AAAAAAAAAJg/Hztgg_U_qlY/s320/modular.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5589526020510392882" /></a><br />Good software developers tend to be organizing freaks: everything goes in a tiny little box in its proper place. You know the saying “there’s no limit to how complicated things can get, on account of one thing always leading to another.” This is especially true in programming.<br /><br />To combat this creeping complexity we strive for modularity and maintainability. A small module that encloses a specific business rule is easier for testing and allows for greater flexibility of reuse. When modules become too small however, the sheer act of tracking them, organizing their use, maintaining consistent versions, and finding where a business rule gets implemented interferes with your productivity.<br /><br />Somewhat counter-intuitively smaller modules also need greater external documentation, mainly to track the nature of the parameters passed between them.<br /><br />What’s the right size for a module then? And how many modules should a
system have? Although I like a module to be between a half and five printed pages it really depends upon two things: how many people are
maintaining the software and the density of the development language.<br /><br />The fewer the number of developers the larger modules can be. Each of you is baking your own cake. So if it’s just the two of you maintaining a legacy billing system written in an old dialect of Basic (that gets about as complicated as a GOSUB and a CALL) then sure, go with the 5-page modules.<br /><br />But if a half-dozen of you are planning to maintain ASP web pages in C# (with overloads and inheritance) then you’d better veer closer to the halfpage module size. In that case you’re not each baking a cake; you’re all contributing to building a car. You need to be able to swap in new replacement parts when the old ones wear thin. Every once in a while step back to review how you are developing the code: are you using appropriately sized modules?</p><br/><p>Jeff Chapmanhttp://www.blogger.com/profile/09414277588527738949noreply@blogger.comtag:blogger.com,1999:blog-6462062627124519421.post-42556295388793515462017-12-15T07:34:00.000-08:002017-12-15T07:34:18.533-08:00Artful Tool Use<p><br />A work acquaintance once posited “if we have the stupid people develop it, then it will be easier to maintain. If the smart people develop it then only the smart people will be able to maintain it.”<br /><br />One of the classic management dilemmas remains how to select the creative workforce for a long-term project (or in software a neverending project) such that the system will not only stay maintainable but that the developers can accomplish the project in a subtle and efficient manner. It’s rather a deep question.<br /><br />Your philosophy towards tool use and the Development Lifecycle may precipitate how you answer this question correctly in your surroundings. Imagine a chart with company strategy on one axis and expected system longevity on the other axis. Then we should ideally expect the mix of tool use and the level of employee expertise to look something like this:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_PRbkgMaKbFU/TMAnQ5TwKPI/AAAAAAAAAHw/919i8K6-mdg/s1600/stupid.JPG"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 298px; height: 193px;" src="http://2.bp.blogspot.com/_PRbkgMaKbFU/TMAnQ5TwKPI/AAAAAAAAAHw/919i8K6-mdg/s320/stupid.JPG" border="0" alt=""id="BLOGGER_PHOTO_ID_5530463513626028274" /></a><br />Legend: HT = high tool, ME = medium expertise<br /><br />At first glance this chart makes little sense: the ranges of expertise and tool use jump about and seem to lack any expected sort of gradient. This is attributable to the two dominions for when tools make a good bet: first when getting a system out fast has high strategic value, and secondly when time or money are likely to constrain your resources.<br /><br />Similarly two situations require a higher level of expertise: when a system has a very specific focused utility and when the company needs the software to survive an expected future path of high business volatility.<br /><br />Choose your tools and your creative workforce to match your company’s strategic plan. This is a key goal of I.T. strategy alignment and helps to avoid the dreaded swamp monster of impedance mismatch.</p><br /><p>Jeff Chapmanhttp://www.blogger.com/profile/09414277588527738949noreply@blogger.comtag:blogger.com,1999:blog-6462062627124519421.post-55212325312472937672017-11-15T07:24:00.000-08:002017-11-15T07:24:38.841-08:00The Art in Empathy<p><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_PRbkgMaKbFU/TIjQO98LmwI/AAAAAAAAAG4/AfbmhffORrI/s1600/Empathy.jpg"><img style="float:right; margin:0 0 10px 10px;cursor:pointer; cursor:hand;width: 122px; height: 157px;" src="http://1.bp.blogspot.com/_PRbkgMaKbFU/TIjQO98LmwI/AAAAAAAAAG4/AfbmhffORrI/s320/Empathy.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5514886699278899970" /></a><br />The continual empathy of your clients is a key component of analysis. A separate entity from your sponsor, the clients are the people who will directly wield your software. Sometimes these folks overlap with the people who paid for the development and sometimes they don’t. Regardless you would do well to heed your clients’ desires as in the long run the clients keep you employed, rather than your sponsor.<br /><br />This may strike a slightly odd chord, but it is akin to pointing out that you are more accountable for keeping your car running than the bank that lent you the money. All the bank cares about is that their loan is paid back with interest. But you will be the person driving your car and how you care for it and drive it determines how long the car will last. Similarly how well your project meets the needs of your clients will determine how long your software stays useful, even though your sponsor is providing the financing.<br /><br />Amazingly enough the client enjoys relating their desires to someone who expresses a genuine interest in their needs and their working environment. You should try to discover what keeps the client awake at night: what are his worries. Nothing pleases a client like a designer who knows his workday life in detail, his daily routines, and what he faces in the way of competition and challenges in his office.<br /><br />Analyze the big picture, not just the snapshot relevant to what you perceive as the scope of your project. Anticipate what the client wants: don’t wait for them to ask. Finally in those instances where you’ve identified a can of worms without a ready solution, consider what alternatives are available to monitor, mitigate, or manage the issue.<br /><br />Interviewing for requirements seems simple enough, yet actually listening to a client discuss his desires takes a considerable amount of insight. You need to understand the sociology of his office and the things he wishes he had but doesn’t know how to ask for. Many times an employee is shy to relate his frustrations after finding that doing so in the past only set him apart as a complainer. You need to commiserate with him (without being smarmy or condescending) and then step back and independently think of ways to improve his working life.<br /><br />Design extends beyond its up-front activity: once you’ve installed the initial version of your software you need to revisit the client to assess the full impact of your creation on his daily activities. The artistic thing to do is to create a system that your client appreciates long after you are gone. Continued empathy is the key for doing so.</p><br /><p>Jeff Chapmanhttp://www.blogger.com/profile/09414277588527738949noreply@blogger.comtag:blogger.com,1999:blog-6462062627124519421.post-92073804794845228502017-10-20T07:24:00.000-07:002017-10-20T07:24:53.313-07:00Artful Hacks<p><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_PRbkgMaKbFU/THz17DK_xyI/AAAAAAAAAGw/2iat4IPTA8I/s1600/hack.jpg"><img style="float:right; margin:0 0 10px 10px;cursor:pointer; cursor:hand;width: 137px; height: 175px;" src="http://2.bp.blogspot.com/_PRbkgMaKbFU/THz17DK_xyI/AAAAAAAAAGw/2iat4IPTA8I/s320/hack.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5511550438807160610" /></a><br />Some I.T. personnel are as far apart as the East is from the West. Three metrics separate the developers from the management:<br /><br />+ Easy to use<br />+ Fast<br />+ Proprietary<br /><br />You see from management's perspective, software and file formats should be fast, easy to use, and universally available. In this way the company avoids being locked in to knowledge experts or particular vendors.<br /><br />The developer however actually prefers the opposite: software and file formats that are cumbersome, resource intensive, and proprietary. In this way he can become an expert and increase his value to his employer.<br /><br />So with both sides pulling in opposite directions what actually gets developed, what can possibly morph into physical being? Somewhere amidst the massive amounts of energy used in the politics and positioning of the two sides something springs up in-between.<br /><br />Irrespective of the methodology employed or the layers of middle management helping to assuage differences, software developed in a corporate environment ends up partially complicated in the more obscure parts, just fast enough to get the job done, and reliant upon one or two inside hacks. It can be no other way.<br /></p><br /><p>Jeff Chapmanhttp://www.blogger.com/profile/09414277588527738949noreply@blogger.comtag:blogger.com,1999:blog-6462062627124519421.post-71424597706153425812017-09-12T08:55:00.000-07:002017-09-12T08:55:55.554-07:00Artful Commitment<p><br />People arrive at the ocean of project management from various rivulets of experience. Some have navigated programming or quality assurance while others set out with a business management education. Regardless of how you get there, once you have responsibility for overseeing the movement of creative team processes you find yourself in the delicate position of asking people to do things.
<br /><br />
To a certain extent folks enjoy being challenged and pushed. They dislike, however, being stressed and overworked. The trick is to find the sweet spot where you commit them to the fair amount of pressure. At the same time folks have their own personal quirks and either tend to over-commit themselves or alternatively play up the amount of time that they are being productive when they are actually socializing instead.
<br /><br />
It’s sort of management science: if you don’t assign the work then who is going to do it? Obviously you want to show some efficiency in completing the workload, but you also want to maintain good morale. This engages several competing foci and proves to be a riveting point in project management.
<br /><br />
And I mean riveting in the sense of steel beam construction: the rivets only go through the steel in strategic locations, and for good reason. A rivet in the wrong place — too close to other rivets or adjacent to a concentration of shear — will weaken rather than strengthen a structure.
<br /><br />
It’s your job when you are managing a project to rivet the team together to make sure that all of the pieces, players, and components are carrying their load under equal stress.<br /></p><br /><p>Jeff Chapmanhttp://www.blogger.com/profile/09414277588527738949noreply@blogger.comtag:blogger.com,1999:blog-6462062627124519421.post-63811488676769477672017-08-16T10:12:00.000-07:002017-08-16T10:12:25.187-07:00The Art in Algebra<p><br />Some aspects of software design feel very much like being mired in the
depths of linear algebra. Once you solicit the requirements from the interested
parties (when you think you know who is responsible for what) and
when you establish the business rules that determine which user input you
require for which circumstances, you end up with a hundred slips of paper
that you somehow need to organize across three dimensions. Time to drag
out the UECF matrix.<br /><br />
This is more of a mental process than an actual formula that delivers a specific
solution. UECF stands for user-event component filter: it means
organizing your system along the axes of roles (users), events (a customer
places an order, an employee gets a raise), and components (what you conceptualize
for the building blocks of your system). Or in object-oriented
design we traditionally call these the use cases.<br /><br />
The essence of the problem is how to translate the use cases into various
screen interface designs. This gets compounded not only by “who can set
what” but also by the level of importance of each data field from the
varying perspectives: we want important items at the top left on the screen,
but what is important for one role may be superfluous for another. The
usual answer is to wireframe a solution.<br /><br />
But this falls short of actually resolving the underlying algebra: how to
organize screen elements as /reusable/ components. With wireframe modeling
you end up with the blind men and an elephant analogy: each user
describes the screen to appear correct but just from their limited exposure
via their own responsibilities. The onus of standing up for a legitimate
component view as it relates to the interface therefore falls squarely on the
shoulders of the designer. You and only you are responsible for the design
of the environment that will afford a proper care to the whole elephant.<br /><br />
Group logically reusable fields into a “tab” of a localized sub form or cordoned
off area, where appropriate. Hey friend, the customer name,
address, phone, and eMail are all a single common logical unit: group them together into a “control.” Of course the same is true for other groups of
fields within your business. And create a matrix… do the algebra!<br /></p><br />Jeff Chapmanhttp://www.blogger.com/profile/09414277588527738949noreply@blogger.comtag:blogger.com,1999:blog-6462062627124519421.post-50237616318986105522017-06-16T09:22:00.000-07:002017-06-16T09:22:06.219-07:00Artistic Test Harnesses<p><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_PRbkgMaKbFU/S9MWKiMyBJI/AAAAAAAAADY/RlTvEbFwjd8/s1600/Harness.png"><img style="float:right; margin:0 0 10px 10px;cursor:pointer; cursor:hand;width: 187px; height: 164px;" src="http://2.bp.blogspot.com/_PRbkgMaKbFU/S9MWKiMyBJI/AAAAAAAAADY/RlTvEbFwjd8/s320/Harness.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5463735143165461650" /></a><br />Modern object-oriented development is primarily cobbling small pieces of reusable functionality together. In the midst of development — during Spring training when you are hitting, running, throwing, and batting all day — you implement very specific business rules in small modules. Given certain input conditions and certain characteristics of the underlying data the invoker expects you to return the right properties or accomplish a persisted change in the data with a specified method.
<br /><br />
Quite frequently the classes doing the heavy-lifting work behind the scenes without any visible interface to the user. How then do you make sure that your modules work properly? And how do you verify they work correctly under different conditions when called by different classes and when the underlying data changes? This job my friend calls for the use of a test harness.
<br /><br />
A good test harness is like an automated batting cage where you can walk in, press a button for sixty mile per hour pitches, and have a machine throw consistent strikes.
<br /><br />
Essentially a test harness is an ugly, quickly thrown together form with a handful of buttons and data-bound fields (or perhaps a data grid) that allows you full access to all of the ways possible to invoke your methods and set or get your public properties.
<br /><br />
I like to use a tabbed interface when I’m building a harness; frequently I develop several objects simultaneously as part of a larger library and each tab tests the features of one of the objects. The complete form thus covers a large chunk of the library. Click a different tab to have a slower or faster pitch thrown toward you.
<br /><br />
The best part about a harness, aside from the convenience it affords to unit testing, is that in the throes and craziness of implementation you can use it for quick and dirty fixes (invoking methods directly rather than bothering a fully implemented interface). Yes you can always take a shortcut and set debug checkpoints to carry out unit tests. But the extra flexibility and thoroughness afforded by a test harness, even though it requires an extra day to throw together, is always well worth the effort.<br /></p><br /><p>Jeff Chapmanhttp://www.blogger.com/profile/09414277588527738949noreply@blogger.comtag:blogger.com,1999:blog-6462062627124519421.post-19975225725817736252017-05-17T10:25:00.000-07:002017-05-17T10:25:47.280-07:00Artistic Options<p><br />
On your browser (under the Tools menu) you will find an item that says "options." And when you are developing code for your employer using the latest IDE, say Visual Studio, you can naturally set the look-and-feel "options." So how is it that within the software you create for your coworkers you left out the Options settings?
<br /><br />
Maybe personalization is of less importance when you have two hundred clients rather than two million, but I also believe that a large part of the failure to personalize is deliberate scope restrictions to begin with. In other words if only twenty percent of the users need to see "purchase history" then we segregate it off to a separate screen. It's as if we pull the oysters off the regular menu since only five patrons regularly order them and they know how to ask for them.
<br /><br />
Occasionally during design you will discover however that several groups of people work on essentially the same subset of data, although you will hear preferences expressed in terms of "I'd rather see it this way." I'd rather have a pulldown list. I'd rather have all the ship-to data on the side.
<br /><br />
Heck, even restaurants that have a tightly limited menu allow you the flexibility to build other victuals given their ingredients. Go to In-n-Out and you can get a 4 by 4 or Animal Style without the carhop even blinking an eye.
<br /><br />
Sometimes screens can be cleaner (and easier to code) if you design from the start with the idea of user-selected optional components or views. You will please more folks if you allow for personalization: expand their options!<br /></p>
<br />Jeff Chapmanhttp://www.blogger.com/profile/09414277588527738949noreply@blogger.comtag:blogger.com,1999:blog-6462062627124519421.post-29473897962934917182017-04-18T12:37:00.000-07:002017-04-18T12:37:47.219-07:00Artistic Auditability<p><br /><a href="http://3.bp.blogspot.com/-L_WN-ns_6u4/T35QtgQ8byI/AAAAAAAAAMI/0XOyReXrCqg/s1600/check.png" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5728104518747189026" src="https://3.bp.blogspot.com/-L_WN-ns_6u4/T35QtgQ8byI/AAAAAAAAAMI/0XOyReXrCqg/s320/check.png" style="cursor: hand; cursor: pointer; float: right; height: 149px; margin: 0 0 10px 10px; width: 155px;" /></a>When you are designing software that updates data based upon business rules, or that creates new rows of data from somewhere else, be sure to pay attention to the creation of a useful audit trail. Yes this is more work than just updating the data or appending new records, but taking the care to do so has several benefits.<br /><br />Folks in the financial or security industries use the terminology of Audit Trail to identify who accessed or changed which records, and when. A business audit trail however can be a more useful resource than for just tracking down suspicious activity. <br /><br />Audit trails are useful both at record-level granularity and also at the file-level of detail. At the record level track the date and time that rows got created or updated, along with the name of the process performing the updates. Along with a timestamp, updates to master tables should also include the user ID and their IP address.<br /><br />When you are making a global change behind the scenes programmatically to a file, create an easily identifiable annotation in a new, otherwise unused field.<br /><br />If you are executing complicated business logic that determines activity that could have material impact to a customer, store the intermediate values along with the timestamp and version information; be sure to save this information for both affirmative actions and those that, in the end, result in no activity (sometimes the questions are about why things didn't happen).<br /><br />For file level auditing it is often useful to have a logging table to track the batch processing of files, indicating a timestamp and overall record counts. Files being passed between systems should have a trailer record that contains both a record counter and a version indicator from the program that created it.<br /><br />Audit trails assist in ferreting out performance problems and flaws in applications. They are also useful documentational research tools when a Support department needs to explain why a particular behavior occurred (or did not occur).<br /></p>
<br />Jeff Chapmanhttp://www.blogger.com/profile/09414277588527738949noreply@blogger.comtag:blogger.com,1999:blog-6462062627124519421.post-73675847989048882082017-03-16T14:07:00.000-07:002017-03-16T14:07:27.475-07:00An Artful Chunk<p><br />A fairly substantial design issue when planning the logical design of a database is how to "chunk" it. I don't mean vertical or horizontal partitions (for performance optimization) nor segmentation for security constraints. Rather, I use the term chunk here to signify how you associate large swaths of data with business processes such that you can restore a subset of the database. <br /><br />Here's an operational example. You have several customers for whom you retrieve monthly or weekly datasets of new input, at random intervals for each customer. After you ingest the data you run three large processes to end up with a pick list of what to ship to each one. Say the whole process takes a couple weeks of elapsed time. <br /><br />One day, after the second big processing step, you are informed that one of your customers sent you the data for the wrong store. What do you do now?<br /><br />Planning for this type of occurrence takes careful attention to detail. Any manual data updates that occur outside of automated production need an audit trail so you may re-apply them after your data is restored. Large aggregation processes need checkpoints or staging tables so you may recalculate after a backout. <br /><br />Making contingencies for large contiguous corrections, from the start of logical database design, is the artful way to safely chunk your database.<br /></p>
<br />Jeff Chapmanhttp://www.blogger.com/profile/09414277588527738949noreply@blogger.comtag:blogger.com,1999:blog-6462062627124519421.post-62439856266348099562017-02-15T09:33:00.000-08:002017-02-15T09:33:00.584-08:00Artistic Teaching<p><br />Any company that has been around for more than six or seven years has had to deal with changes in the technology stack. Naturally this has serious implications to the clerical staff: those that actually deal directly with the customers. Of course most successful companies hire employees who are quick to learn anyhow. Yet when you have major system wide changes, it is of tremendous help to have a couple folks on board who are both astute at learning on their own as well as at communicating to and teaching the new technology to others.<br /><br />It takes a certain type of personality to be comfortable with teaching coworkers: this is not like an elementary school teacher nor even a college professor. To be effective the instructor needs to be comfortable enough in their own learning abilities to stay "ahead of the curve" and hence secure in their position.<br /><br />They need to possess patience for those who are slower to grasp new concepts, and yet appreciate the effort their fellow employees are making, and have a means to be continually encouraging. Companies that have found the keys to long term survival have also found how to keep their internal "teachers" engaged and on board.<br /></p>
<br />Jeff Chapmanhttp://www.blogger.com/profile/09414277588527738949noreply@blogger.comtag:blogger.com,1999:blog-6462062627124519421.post-91880454456585824102017-01-16T07:37:00.000-08:002017-01-16T07:37:19.150-08:00Artful Champions<p><a href="http://2.bp.blogspot.com/-x77J9wELCk8/TwHNpjgEqzI/AAAAAAAAALY/CMf7fAnfwSg/s1600/trophy.jpg" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5693057517761112882" src="https://2.bp.blogspot.com/-x77J9wELCk8/TwHNpjgEqzI/AAAAAAAAALY/CMf7fAnfwSg/s320/trophy.jpg" style="cursor: hand; cursor: pointer; float: right; height: 213px; margin: 0 0 10px 10px; width: 176px;" /></a><br />There's an old saying, "every social war is a battle between the very few on both sides who care and who fire their shots across a crowd of spectators." Analysis is very much like that. You have perhaps two or three managers who have different opinions about what your objectives should be, and a couple large groups of customers who care in the collective sense, but who individually just view your project with the valid skepticism of the small part it plays in their lives. <br /><br />To really nail down the ethos, and for a large project to succeed, you need to have (or manufacture) a champion for each of the user, customer, and business interest groups. These champions needs to sincerely stand up for the benefits and beliefs of their group, and be gregarious enough to express them.<br /><br />As you cycle through the balance points you then build up goodwill amongst the champions, and this enables you to negotiate concordance on the more difficult decisions. <br /><br />This can be an especially hard sell: first, when a champion is less than sincere in standing up for their group. Secondly, when a champion changes employment, through their own choice or otherwise. And thirdly, when you can't get sufficient permanent heavy artillery support from a senior manager to resolve those instances where negotiations fail. <br /><br />A solid 25% of full-metal Analysis involves the psychic steps to avoid these three pitfalls.<br /></p>
<br />Jeff Chapmanhttp://www.blogger.com/profile/09414277588527738949noreply@blogger.com