TweetFollow Us on Twitter

May 93 - Solution-Based Modeling: A Methodology for the Rest of Us

Solution-Based Modeling: A Methodology for the Rest of Us

Jeff Alger and Neal Goldstein

This article is the second of two parts, much of which is excerpted from a forthcoming book by Jeff Alger and Neal Goldstein. Copyright © 1993 by Jeff Alger and Neal Goldstein. All rights reserved. The first part appeared in the March issue of Frameworks.

Review From Part I

Solution-Based Modeling and its companion notational system, the Visual Design Language, were developed to map well to the way creative people work best while still allowing management to estimate, schedule and maintain control. The objectives are to improve communications, decision-making and, as a consequence, the success rate of projects, chiefly through improving communications and decision-making.

There are three basic components of SBM.

  • An architecture that structures analysis, design and programming information into a series of well-defined models.
  • A notation, VDL, that can be used to define and express the models with minimal loss and distortion of information.
  • A process for overall development that pays attention to the needs of all parties to the project, from end users to management to engineering to quality assurance and documentation. This includes modeling technology that helps teach people how to build robust, complete models, alone or in work groups, and continuous quality assurance structures: algorithms and metrics that make quality software a consequence of the overall process, rather than the result of a separate step.

The architecture and notation were discussed in the first part of this article in the March issue of Frameworks. This part focuses on the process and briefly discusses a fourth component, tools, currently under development by SBM International and others. Extensions to the method are also discussed. Before proceeding, let us review briefly the overall architecture and notation discussed in the first part.

Architecture

There is growing acceptance in the software engineering community today of the so-called "multiple models" approach: dealing with a single subject by building many overlapping models. In SBM, we create a series of models of the following kinds.
  • Business models describe the business system that surrounds the computer system or program.
  • Conceptual models are idealized, or deliberately simplified, models of the content and interface of the program.
  • Run-time models describe the running program and ignore implementation details about how the source code is structured.
  • Implementation models collectively are the implementation, expressed as a combination of source code and design diagrams.

We call these four kinds of models planes and name them the Business, Technology, Execution and Implementation planes, respectively. Within each plane, we use the term region to describe one model of that kind.

Notation

The Visual Design Language (VDL) was designed in conjunction with graphics design experts and tested to enhance comprehension and retention of information in software projects. VDL emphasizes the use of small, self-contained diagrams called scenarios. An SBM project uses scenarios as the way to capture, communicate and validate business, conceptual design, software architecture, and programming informations. Scenarios typically overlap heavily in content and subject matter. Within any scenario there are elements and relationships among those elements. Provision is made for both static scenarios, in which time is not a factor, and dynamic scenarios that show a flow of action of state over time.

Process

There are four basic activities in a SBM project:

  • Creating new scenarios,
  • Validating scenarios,
  • Programming, and
  • Managing the project and library.

Creating New Scenarios

Participants in the team draft a series of simple scenarios, each of which concentrates on a single topic. The overall "model" is, in a sense, simply the collection of valid scenarios gathered during the project. SBM encourages and supports exploration of problems at or near the basic level, rather than using a top-down approach. However, to abandon top-down approaches without a substitute process in place would be foolish, since one still needs defined starting points and controlled, incremental expansion. To address this problem, SBM relies on centrality. Let's revisit the jigsaw puzzle analogy. Once the border is in place, what do you do next? Most people would pick some interesting topic, perhaps a building or a flower, and work on that pattern for awhile. When work on that topic bogs down, one shifts to some other central topic. Eventually, one works out toward the periphery perhaps connecting topics to each other or to the border. Finally, when there is nothing left but blue sky, the final, hard work begins.

This so-called center-periphery strategy is precisely the exploratory process used in SBM. It is such a natural process that it doesn't need to be formally taught; you already use it every day. In fact, even when people are asked to work in other ways, such as top-down, they end up using center-periphery strategies and make it look otherwise. SBM merely provides an environment in which it is safe and politically acceptable to run entire projects this way.

  1. Start with a central topic.
  2. Blanket that topic with small, overlapping scenarios in several regions of the overall four-plane model.
  3. When that bogs down, pick another central topic and iterate.
  4. As the model fills out, spend more and more time on the periphery.
  5. When the overall structure of the project is well-established, do the fine detail work.

Notice that this not only does not require a top-down process, it also does not force a linear approach. That is, one is free to shift focus from plane to plane and region to region at any time, rather than having to finish one region before starting on the next. This, too, is simply the way people work whether you want them to or not. In SBM, we recognize that fact and design project management strategies around it. This is the essence of the multiple models approach: rather than viewing a problem from one direction only, we continually turn it around in our hand, considering it from multiple perspectives in order to gain a more complete understanding.

VDL and the scenario paradigm are useful in many different contexts, from a software engineer scribbling at a white board to interviews with people outside the central project team to a focus group of typical end users being asked to provide critical feedback to product marketing to briefings for management on the state and objectives of the project. This is not random chance: VDL was specifically designed to appeal to a broad cross-section of team participants and "level the playing field" of communications.

Validating

The process described above releases the creative juices. People are free to follow their creative flow in the most productive way, unencumbered by an artificial process. However, eventually one must return to hard reality: the scenarios and models must be formally validated. To that end, SBM uses a series of validation strategies collectively called calibration.
  • Synthesis is used to ensure that scenarios are mutually consistent.
  • Correlation assures that multiple models are consistent with one another and each is complete in terms of the other.
  • Synchronization tests for completeness and consistency of the final architecture within itself.

Synthesis is a term borrowed from data modeling. Gather a set of scenarios, then compare them pairwise to remove any contradictions that may exist, such as synonyms and homonyms. These and other synthesis problems are really just common sense and most people have no problem recognizing them when two scenarios are laid side-by-side. With a small batch, one can simply spread them on a table and compare them pairwise visually. This quickly breaks down as the number of scenarios grows, so larger sets require the use of a cross-reference index that quickly answers requests such as "tell me all the scenarios in which object X occurs." The database support for this sort of query is surprisingly simple; in our book we describe a simple Hypercard-like database that has been used by a number of project teams to good effect. However, there is no substitute for a good automated tool here and this is a major focus of our own efforts today.

Correlation has already been described briefly: matching up one model with another through the correlation relationships Implements, Replaces and Same As. All, or a clearly defined subset (e.g., the program element of the Solution Model), of one model must be completely accounted for in the other model; in turn, each element of the other model must support some aspect of the original.

Synchronization is a series of five separate tests, all applied rigorously in the Execution Plane to validate the completeness of the run-time model. The synchronization tests are

  • Creation, validating that objects and data structures are created before use,
  • Destruction, validating that objects and data have not been destroyed prior to use,
  • Object Knowledge, that is, demonstrating how an object obtains the address of another prior to sending it a message,
  • Connectedness, validating that each method is called in response to some user or operating system event, and
  • Protocol, making sure that the calling protocol for methods is consistent throughout the model.

The first three of these are closely related and apply to all collaborations, both for the objects at each end and the inputs and outputs that make up the calling protocol of the method: For each, demonstrate that it was created in time, hasn't been destroyed, and the originating object has the required object knowledge. These tests apply equally to primitive data structures.

In a procedural program, where the branching logic is hierarchical, it is easy to tell when a subroutine cannot possibly be reached. In an event-driven world of graphical user interfaces, it is not quite so simple to tell what is and is not reachable. Enter the connectedness test. A method is connected if it is called in response to some event. Events can include user activities like mouse clicks, operating system events such as timer interrupts, or higher-level events such as messages from collaborative applications. The basic algorithm works as follows.

  1. Enumerate all sources of events.
  2. For each one, mark the method or methods called directly in response by the operating system or class library.
  3. For each marked method, mark its collaborators; that is, the other methods it calls. Apply this step recursively until no more methods can be marked.
  4. Find all unmarked methods. These are unconnected.

Unconnected methods may indicate any of several underlying problems: synonyms, vestigal code, missing collaborations, or methods put in place to support future expansion.

The protocol test is also quite simple: is any given method always called with the same formal argument types? This is commonly handled as part of synthesis; if not, it must be a separate step as part of synchronization.

The combination of these five tests, applied to the Execution Plane, is designed to uncover the problems that occur in the worst nightmares of project managers and architects. It has been estimated that 50% of a C++ programmer's time is spent tracking down memory leaks and dangling pointers, the subject of the first three of the synchronization tests. Our own surveys show that these tests address problems typically associated with 30%-40% of the programming phase of a project, and that when they occur there seems to be an unwritten rule that they occur at the eleventh hour and cause maximal damage to class hierarchies, QA test suites, and team morale. What SBM does is take these out of the domain of programming and deal with them as design issues.

We can now complete the center-periphery process described earlier by taking into account the three forms of calibration. The result is that of Figure 4, with frequent iterations at all steps.

Programming

A wealth of detail already attended to, programming in SBM projects is considerably easier than in many other approaches. There are two aspects to programming: designing class hierarchies and writing the code that implements methods. In SBM, classes are designed to optimize the implementation; they are not required to have any intrinsic "meaning." Hierarchies are designed to maximize reuse within the project while also maximizing modularity and independence. The process is basically bottom-up in designing interfaces and both bottom-up and top-down in designing implementations of methods.
  1. Group run-time objects of the Execution Plane into concrete types. All members of a concrete type share identical attributes, methods, interfaces and collaborators.
  2. For each type, create a concrete class in the Implementation Plane.
  3. Look for patterns of similarity among the concrete classes. Where such patterns exist, abstract classes are often formed to maximize sharing of properties across concrete classes.
  4. As methods are implemented, differences in behavior, thought not protocol, emerge that lead in the opposite direction: derivation of subclasses that differ in method implementation but not interface.

Managing

In managing SBM projects, everyone on the team should understand at least the following basic subjects:
  • Goal-directed phases,
  • Prototyping,
  • Estimation and the SHP formula,
  • Library management, and
  • Team management.

Goal-Directed Phases

In classical software project management, a phase is considered complete when some activity is complete. Thus, an analysis phase is complete when one is through doing analysis activities. This is in direct opposition to one of the basic principles of SBM, non-linear workflow. Fortunately, other fields have long used more sophisticated strategies in which phases of project plans are orthogonal to the activities that take place within those phases; we adapt those to the world of software development. For example, when a construction firm builds a bridge, it may go through several phases: site preparation, falsework (the temporary frame prior to pouring concrete), and so on through final cleanup. In each phase, there may be planning, design, construction, supervisory and other activities. One can tell that a given phase is complete when certain objectives have been met, independent of the activities used to get there.

In SBM projects, there are three phases between the time the project is identified and launched and the time of the final QA and shipping cycle: analysis, design and programming. Each of these phases has a defined objective to be reached.

The analysis phase is complete when

  1. Someone in authority certifies that the Business and Technology Planes cover all intended scope,
  2. All scenarios of those planes are synthesized with one another,
  3. The Technology and Business Planes fully correlate to one another, and
  4. A credible, detailed project plan is in place for the design phase.

Notice that these objectives do not require working in any particular order within the top two planes of the model. One can freely move around from region to region as long as all regions are complete by the end of the phase. In fact, there is nothing in these objectives that gets in the way of design or programming work during the analysis phase; that is, prototyping.

The design phase is complete when

  1. The Execution Plane and Technology Plane fully correlate,
  2. All scenarios of the top three planes are fully synthesized,
  3. The Execution Plane has been fully synchronized, and
  4. A credible, detailed project plan is in place for the implementation phase.

Again, this says nothing about the specific activities used to get there. One will, of course, spend a great deal of time doing design work in the Execution Plane, but there will also be refinement to the upper planes (analysis) and prototypical programming and class design.

The implementation phase is complete when

  1. The Implementation Plane and Execution Plane fully correlate,
  2. All scenarios in the model are fully synthesized, and
  3. All methods have been implemented and passed engineering QA.

During this phase there will be a mixture of programming, design and some analysis activities.

It might seem at first glance that these objectives are internally inconsistent. After all, we said that the analysis phase is not done until the top two planes are complete, yet asserted that during the design and programming phases we would revise the top two planes. There really is no contradiction. During the analysis phase, new ideas and requirements are injected from outside the model. During the last two phases the only changes made to the upper two planes are the result of correlation from below

Prototyping

Putting all this together, we can identify a target plane for each phase. For the analysis phase, the target is the Technology Plane; for design, the Execution Plane; and for implementation the Implementation Plane. This concept of a target plane allows a broader framework for an age-old subject: prototyping. In SBM, prototyping is work below the target plane of the current phase. During the analysis phase, coding is certainly prototyping, but so is drafting design or class hierarchy scenarios. During the design phase, coding and class hierarchy design are both forms of prototyping.

Few methodologies have really come to grips with the problems of managing prototyping. Prototyping is often used as a substitute for analysis and design, rather than a complement to them. In SBM, we provide a sound theoretical and practical framework for prototyping. A prototype is undertaken to help achieve the objectives of the current phase. During the analysis phase, for example, it may be unclear what user interface has the best look and feel, or whether a key algorithm with acceptable performance can be found to implement some concept of the Content Model. In each case, prototyping is in order. We clearly identify the objectives of the prototype, then pick the form of prototype most suited to answering those questions. Prototyping is not an exception to our phases, but rather fits smoothly within them.

Estimation

SBM takes a fresh approach to the whole subject of estimation by returning to a simple basic premise: the purpose of estimating is to provide sound information on which to base decisions. Perfect estimates that arrive too late are unacceptable. Our estimates have to be available early enough to be useful when the most important decisions regarding scope and resources are being made, even if it means using approximations. Furthermore, the process by which estimates are made must be understandable to all, so that every member of the extended team understands the impact their own decisions have on whether the project comes in on time and within budget. Estimation in SBM is based on a simple formula we call the "SHP" (pronounced "ship") formula:

Scenarios = Human Resources * Productivity

Scenarios represent quantities of throughput for the project. That is, we can measure the "size" of a project by counting how many scenarios it creates. This has proven to be an extremely useful metric, much more useful than any other quantification we have considered and a considerable improvement over conventional metrics such as lines of code or function points. Be careful about interpreting this number, however. The number of scenarios is used to quantify all work, not just activities directly related to scenarios. This includes research, interviews, team meetings, coding, and general overhead activities.

Human resources are measured in person-days and productivity is measured in scenarios per person-day. That is, take the number of scenarios drafted, reviewed and calibrated by the team as a whole and divide by the number of person-days during that period. Our studies have shown that productivity is remarkably consistent across team sizes, platforms, even team experience (more experienced personnel simply get more done with fewer scenarios) at about 1.2 scenarios per person-day. The lowest number we have seen is 0.8, the highest 1.7, with a strong cluster centered on 1.2. (Until organizations gather statistics of their own, we recommend a conservative working estimate of 1.0 scenarios per person-day.) This fact makes the SHP formula a useful one for predicting how long a project will take: if you can estimate how many scenarios will be required, you can predict how long the project will take.

We combine the SHP formula with the statistic that 50% of development efforts go toward analysis activities to come up with a unique approach to software estimation. We assume that the estimators are wrong; in fact, consistently wrong. But by sampling a small subset of the estimate, then extrapolating the results to the overall "guestimate," we can converge on a statistically valid estimate for the project. It works something like this.

  1. You guess that it will take 600 scenarios to complete the analysis phase, based on adding up smaller estimates for individual topics of the Reference and Solution frames.
  2. Sample one or more of those topics by breaking them down into a finer-grained estimate based on subtopics. Suppose, for example, that the sum of the finer-grained estimate for a given topic is 50 scenarios, where the previous guess for that topic was 40. Extrapolate by increasing all other topics by 25%. The new estimate is 750 scenarios.
  3. Sample one subtopic by actually doing the analysis work through to completion. Compare the actual number of scenarios, say, 16, against the estimate for the subtopic, say, 12, and extrapolate the ratio of the original estimate to the actual experience. The new estimate in this example is 1000 = 600 * 50/40 * 16/12.
  4. Continue to sample in this way until the estimates converge with the samples.

There are a couple of minor subtleties to this process, such as accounting for the appearance of new, unanticipated topics during sampling, but this is the basic strategy. It is quick, reliable, and easy to explain, even to people who have no experience with software development. It also does not rely on completing more than a small sample of the analysis before yielding useful information about the size of the project. For most projects, a good, early estimate can be achieved within two to four weeks of the start of the analysis phase.

Not only is an early estimate possible, but the numbers - scenarios and human resources - take at most fifteen minutes a week to gather as the analysis phase proceeds. This makes it possible to generate a new estimate each week, adjusting scope smoothly each Monday to keep the project on track against its baseline delivery date. Thanks to sampling, features can usually be cut before the investment is made in their analysis.

Library Management

SBM and VDL are designed to make the primary means of documenting a project also the most convenient way for team members to take notes or scribble ideas. That is good, for it minimizes the time interval between creativity and documentation and minimizes the translation needed once information is captured. As we have discussed, this strikes at the heart of communications problems in software projects. This means that much, much more information is captured in paper or electronic form than is normally the case in software projects. We have found it not unusual for a project team to assemble three to ten times as much documentation, measured in terms of pages, than would normally be the case, but without slowing down the project in the process. That is almost a Holy Grail of software engineering. With that benefit, however, comes a cost: simply keeping track of the scenarios and keeping them current and calibrated.

There is no question that managing that much paper or a database that size, depending on the form of automated support used, is a major part of project management.

team Management

No method should be considered complete unless one maps it on to the sorts of day-to-day decisions faced by team members, including project managers. There are two areas of project management that deserve mention here: the structure of the project team and the use of SBM and VDL as a means of addressing classic problems of communications, decision-making and people management.

SBM recognizes the following decision-making roles, or areas of specialization (though in a typical project more than one area may be handled by a single person). This is in addition to overall project management.

  • Business Analyst. Responsible for completion of the Business Plane.
  • Content Architect. Responsible for completion of the Content Model and Content Architecture.
  • User Interface Architect. Responsible for completion of the UI Model and UI Architecture.
  • Environment Architect. Responsible for completion of the Environment Model and Environment Architecture.
  • Software Engineer. Responsible for the Execution and Program Planes (thus overlapping the three Architects). Decisions are focused on optimization, synchronization, and software engineering issues such as modularity and reuse.
  • Project Librarian. In a medium-to-large project, this should be a dedicated position, rather than have everyone do their own cataloguing and calibrating. Responsible for maintenance of the library of scenarios and for seeing to it that calibration is done completely and at the right time.

In each case, these are the people who are accountable for seeing to it that the work in their respective areas gets done, even if they do not personally do all the work. They also should carry the authority to make final decisions in those areas. These roles correspond to the sorts of skill sets commonly found in a single individual. They also concentrate related areas of decision-making.

Productivity is constrained by many factors, but at the top of the list are interpersonal, team-centered issues. We wrote earlier of the dominant personality problem: an individual with strong verbal skills and an aggressive personality often dominates project decision-making, all out of proportion to differences in skill level. VDL helps level the playing field by diminishing the roles of both verbal skills and personality. Anyone can learn to use VDL quickly and calibration demands that everyone's input be accounted for.

SBM and VDL also make it feasible for people to work separately or in teams of two, then integrate the results. This is otherwise difficult to do because the media of expression are not formalized enough to support the equivalent of synthesis. As a result, more decisions are made in group settings than is really healthy or productive. In SBM, we recommend a process we call "come together-break apart": one hour per day the team meets as a group to review work done by each other and identify and prioritize needs for new work. In the remaining time, team members work individually or in teams of two, resolving To Do items from scenarios already done. Breakout sessions are also used to revise work based on group feedback, catalog it, and calibrate. This process is not only more efficient than group meetings, since in a group only one person can (or should) be talking at a time, it also leads to better decision-making.

During group sessions, a printing white board is invaluable. It is used to sketch VDL scenarios - and the all-important To Do lists - as the group deliberates. More than a medium, it becomes a means of reaching agreement. Whoever holds the marker has a finger hovering over the "print" button and says, "Are we agreed? Going once… going twice… print!" Everyone in the room knows that agreement was reached and gets a copy of the result. VDL facilitates this because the medium is consistent, not the result of individual style or whim.

The estimation strategy outlined above makes possible a new model for accountability in software projects: the extended team, including engineers and non-engineers, is jointly responsible for meeting the deadline for completion of the analysis phase. The engineering team is then responsible for completion of the design and implementation on time. This seemingly simple change has a profound impact on the quality of decision-making.

These may sound like common sense or even trivial matters, but they are not. These sorts of issues are very important to the success or failure of entire projects, and are therefore not just petty interpersonal issues. SBM and VDL greatly facilitate the basics of people management: communicating, reaching agreement, making team productivity as close as possible to the productivity of one person times the size of the team. We are amazed at the lack of attention these issues have received in other methodologies given their impact on outcomes of projects.

Extensions to the Basic Method

SBM is actually a special case of a more general approach to managing change. For example, there are straightforward extensions that handle the full maintenance lifecycle, distributed systems, and large projects broken down into smaller subproject teams. It is also relatively easy to extend the approach to support future object-oriented frameworks that will not have clear boundaries between "applications," but rather what we call "object soup:" objects firing messages off to other objects without regard to application-level protocols.

We have also heard from a number of people who have been using SBM and VDL purely for their strength in business modeling, even if no software development is under consideration. The techniques of visualization, communication, decision-making and validation are as important for introducing change to businesses as they are for systems development projects. In fact, we view this as the largest future market for the SBM approach.

Finally, because of the modular, scenario-based form used to express analysis and design, SBM and VDL make it practical to reuse analysis and design scenarios across projects. With all the hoopla about reuse of code (notable for the lack of real success), a simple fact seems to have been forgotten: most of the money spent on software development is spent on analysis and design, not code. At this time we are working with several organizations on repositories of analysis and design scenarios to be used across projects. We also feel this presents an opportunity to create an entire new industry: production and sale of analysis and design "packages."

Automated Support

SBM and VDL can be supported with an extremely simple database, one that can be assembled in under a day with any consumer database product. Many SBM projects have been run completely manually, though not without a good deal of grumbling. Clearly, though, SBM could benefit from good, automated support.

The least important problem is graphic support, that is, drawing pretty pictures. This occupies a small fraction of the overall human resources in a SBM project. Instead, the focus should be on two issues that do take up a lot of time: calibration and browsing. The browsing is particularly important, answering such questions as "show me all the scenarios in which object X appears" or "show me all the responsibilities (or collaborators or parts…) of object X across all scenarios."

It is also important to maintain the basic principles behind SBM: non-linear and non-hierarchical flow, multiple models, visual communication, and defering calibration until creative flow has slowed. This combination has made it difficult for CASE vendors to support the methodology to date. ("Of course, we'll have to get rid of the 3D notation, divide everything up into three different tools to be used linearly, constrain the use of VDL to well-defined syntax, and otherwise change it all around, but SBM is great and we'd like to support it!") Despite this difficulty, we have recently been approached by several CASE vendors about proposed extensions to their products. As SBM continues to grow in popularity we expect this trend to continue until SBM is widely supported.

In the meantime, SBM International will soon be releasing a series of tools specifically designed to support SBM. As of this writing, the first of these tools , the VDL Companion™ modeling tool, is in beta test and should be in final release by the time this article is published. Higher-end products are being worked on that will support calibration algorithms (VDL Professional™) and multi-user repositories (VDL Teamware™). These are designed to maintain the spirit of SBM and VDL: non-linear, visual, non-hierarchical and supporting very flexible use of VDL for introducing new idioms.

SBM International provides consulting, training and tools that support the use of SBM. For more information, contact the authors at (415) 424-9400, FAX (415) 857-0198, or at 3124 South Court, Palo Alto, CA 94306.

 

Community Search:
MacTech Search:

Software Updates via MacUpdate

Hopper Disassembler 5.6.1 - Binary disas...
Hopper Disassembler is a binary disassembler, decompiler, and debugger for 32- and 64-bit executables. It will let you disassemble any binary you want, and provide you all the information about its... Read more
Skim 1.6.11 - PDF reader and note-taker...
Skim is a PDF reader and note-taker for OS X. It is designed to help you read and annotate scientific papers in PDF, but is also great for viewing any PDF file. Skim includes many features and has a... Read more
Alfred 4.6.7 - Quick launcher for apps a...
Alfred is an award-winning productivity application for OS X. Alfred saves you time when you search for files online or on your Mac. Be more productive with hotkeys, keywords, and file actions at... Read more
Transmit 5.8.7 - Excellent FTP/SFTP clie...
Transmit is an excellent FTP (file transfer protocol), SFTP, S3 (Amazon.com file hosting) and iDisk/WebDAV client that allows you to upload, download, and delete files over the internet. With the... Read more
Adobe Lightroom Classic 11.4.1 - Import,...
You can download Lightroom for Mac as a part of Creative Cloud for only $9.99/month with Photoshop, included as part of the photography package. The latest version of Lightroom gives you all of the... Read more
MarsEdit 4.5.9 - Quick and convenient bl...
MarsEdit is a blog editor for OS X that makes editing your blog like writing email, with spell-checking, drafts, multiple windows, and even AppleScript support. It works with with most blog services... Read more
Thunderbird 91.11.0 - Email client from...
As of July 2012, Thunderbird has transitioned to a new governance model, with new features being developed by the broader free software and open source community, and security fixes and improvements... Read more
A Better Finder Rename 11.50 - File, pho...
A Better Finder Rename is the most complete renaming solution available on the market today. That's why, since 1996, tens of thousands of hobbyists, professionals and businesses depend on A Better... Read more
DaisyDisk 4.23 - $9.99
DaisyDisk allows you to visualize your disk usage and free up disk space by quickly finding and deleting big unused files. The program scans your disk and displays its content as a sector diagram... Read more
BBEdit 14.5 - Powerful text and HTML edi...
BBEdit is the leading professional HTML and text editor for the Mac. Specifically crafted in response to the needs of Web authors and software developers, this award-winning product provides a... Read more

Latest Forum Discussions

See All

Downhill Mountain Biking Game ‘Descender...
Just over three years ago in May of 2019 developer RageSquid and publisher No More Robots released a quirky downhill mountain biking game called Descenders on PC and Xbox One. Bemoaning a lack of “extreme sports" titles in recent years led RageSquid... | Read more »
SwitchArcade Round-Up: ‘Monster Hunter R...
Hello gentle readers, and welcome to the SwitchArcade Round-Up for June 30th, 2022. Thursday is once more upon us, and that means a bunch of new releases to look at. We start things off with DLC for some very big games, Monster Hunter Rise and... | Read more »
‘HOOK 2’ Review – A Sharp Left Hook From...
The original HOOK ($1.99) had a very simple idea behind it. You were presented with a tangled mess of hooks and loops, and you needed to remove each one without snagging any others. Extremely simple at first, but as the puzzles rolled along,... | Read more »
‘Dicey Dungeons’ Mobile Version Launchin...
After a very long wait, Terry Cavanagh’s dungeon crawling roguelite deckbuiler hybrid experience Dicey Dungeons is coming to mobile platforms next week alongside a huge free DLC pack on all platforms. This DLC will be included in the mobile... | Read more »
Distract Yourself With These Great Mobil...
Every day, we pick out a curated list of the best mobile discounts on the App Store and post them here. This list won't be comprehensive, but it every game on it is recommended. Feel free to check out the coverage we did on them in the links below... | Read more »
‘Danganronpa S: Ultimate Summer Camp’ is...
If you’ve been following Danganronp over the last few years, Spike Chunsoft celebrated its anniversary by bringing the series to mobile in the form of anniversary editions. After the first two released, there was a long delay for V3, but it finally... | Read more »
Out Now: ‘HOOK 2’, ‘Incoherence’, ‘Juras...
Each and every day new mobile games are hitting the App Store, and so each week we put together a big old list of all the best new releases of the past seven days. Back in the day the App Store would showcase the same games for a week, and then... | Read more »
Upcoming Mobile MMO RPG Shooter ‘Avatar:...
This past January a contingent of developers made up of Archosaur Games, Tencent, Lightstorm Entertainment, and Disney announced a new mobile game set in James Cameron’s Avatar universe titled Avatar: Reckoning. | Read more »
Culinary Platformer ‘Chefy-Chef’ Coming...
If your name is Chefy, it’s pretty much a given that you should be a chef. Such is the case with Chefy-Chef, a game from Bug Studio about a chef named Chefy who must travel to all sorts of exotic locations using a magical refrigerator in an effort... | Read more »
SwitchArcade Round-Up: Nintendo Direct H...
Hello gentle readers, and welcome to the SwitchArcade Round-Up for June 29th, 2022. As the month winds to a close, we’ve got a bigger-than-usual Wednesday for both news and new games to check out. I’ve got some crib notes for yesterday’s Nintendo... | Read more »

Price Scanner via MacPrices.net

2nd generation 4K Apple TVs with Siri remote...
Apple has restocked a full line of Certified Refurbished 2nd generation 32GB and 64GB 4K Apple TVs with Siri remotes for $30 off the cost of new models. Apple’s standard one-year warranty is included... Read more
Back in stock: Apple Watch Series 7 models fo...
Apple has restocked Certified Refurbished Apple Watch Series 7 WiFi-only models in their online store for $60-$70 off MSRP, starting at $339. Each Watch includes Apple’s standard one-year warranty, a... Read more
July 4th Sale at Expercom: $200 off any 16″ M...
Apple reseller Expercom has 16″ M1 Pro and M1 Max MacBook Pros available for $200 off MSRP as part of their July 4th sale. In addition to their MacBook Pro sale prices, take $50 off AppleCare+ when... Read more
10.2″ Apple iPads (WiFi models) are on sale f...
Amazon has Apple’s 9th generation 10.2″ WiFi iPads on sale for up to $20-$50 off MSRP for a limited time. Their prices are the lowest price currently available for one of these iPads. All models are... Read more
10-Core M1 Pro 14″ MacBook Pros on sale for $...
B&H Photo is offering $200 discounts on Apple’s new 14″ M1 Pro MacBook Pros with 10-Core CPUs (16GB RAM/1TB SSDs). Free 1-2 day shipping is available to most US addresses, and both models are in... Read more
B&H has 16-inch M1 Pro MacBook Pros in st...
New Space Gray 16″ MacBook Pros with Apple’s M1 Pro CPUs are in stock and on sale today at B&H Photo for $200 off Apple’s MSRP. Sale prices are for M1 Pro models with 512GB or 1TB of SSD storage... Read more
Price drop! 13″ M1 MacBook Pro with 512GB SSD...
Amazon has dropped prices on recently-discontinued 13″ M1 MacBook Pros with a 512GB SSD by $200 off Apple’s original MSRP. Shipping is free: – 2020 13″ MacBook Pro (Space Gray or Silver) M1 CPU/512GB... Read more
Deal Alert! 14″ Apple MacBook Pros with M1 Pr...
Amazon has 14″ MacBook Pros with 8-Core M1 Pro CPUs back on sale for $200 off MSRP, only $1799. Shipping is free. Be sure to make your purchase from Amazon rather than a third-party seller: – 14″ M1... Read more
16″ MacBook Pros with Apple M1 Pro CPUs are b...
Amazon is discounting new 16″ MacBook Pros with 10-Core Apple M1 Pro CPUs by $200 off MSRP again today. Be sure to select Amazon as the seller rather than a third-party seller, and note that Amazon’s... Read more
13″ M1 MacBook Airs with 16GB of RAM availabl...
Apple has 13″ M1 MacBook Airs (8-Core CPU/7-Core GPU) in stock today with 16GB of RAM for $190 off MSRP, Certified Refurbished. Apple includes a standard one-year warranty with these models, each... Read more

Jobs Board

I/S Senior Engineer - *Apple* Systems Engin...
**19647BR** **Position Title:** I/S Senior Engineer - Apple Systems Engineering - Remote **Department:** Information Systems **Location:** Lakeland, FL between Read more
*Apple* IT Support Analyst - 2nd Shift - Zon...
Apple IT Support Analyst - 2nd Shift Professional Services Albany, New York Malta, New York Clifton Park, New York Menands, New York Syracuse, New York Watertown, Read more
Infotainment Certification Test Engineer (XC)...
…integration - CarPlay, android auto, MirrorLink, Baidu Carlife, MFi/iPod certification testing; Apple PPID preparation, Google HUCD and GTM preparation + 3 years of Read more
Workplace Services *Apple* Device Managemen...
…3350 Riverwood Parkway Suite 900, Atlanta, GA, 30339 USA **Workplace Services Apple Device Management** **Role Overview** Carrier is seeking an experienced and Read more
Physician Assistant - Certified, Primary Care...
Physician Assistant - Certified, Primary Care, Apple Valley (1.07FTE) + Job ID: 65766 + Department: AV Primary Care + City: Apple Valley, MN + Location: HP - Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.