Just Enough Technology » Process (SDLC)

Why Just Enough Technology?

Dave Ranck — Mon, 01 Feb 2010 01:35:42 +0000

Just Enough Technology means providing the right technology to solve the right problem at the right cost. Not too much, not too little. The objectives of the business must be prioritized and kept in mind from concept to design to implementation to maintenance. Every decision made along the way must map to a business objective. Every software requirement must map to a business objective. This is the foundation of Just Enough Technology – clear and concise business objectives. Those objectives drive the requirements, and the requirements drive the design and implementation.

This is how I ended a short article about Just Enough Technology a while back. I’ve reproduced here for your reading pleasure. Differing opinions are invited

I’ve worked with many Fortune 500 and 100 clients, as well as small and mid-size companies. While there are many differences between the big guys and the smaller guys, they share one thing in common: the bottom line is their bottom line. Any business is in business ultimately to do one thing: make a profit. True, there are other drivers that individual companies may have, whether it is being a market leader or providing a service for the betterment of humanity. No business can stay in business unless they achieve a positive bottom line. I’m sure everyone understands this basic truth and yet, when it comes to creating, purchasing and maintaining software and perhaps to a lesser extent, hardware, this principle is often left by the wayside. One case in point I’m reminded of was a project for a national company (a household name you would recognize). This company undertook an integration project several years ago and engaged a large consulting firm to create a design and to do the implementation. The project began and the company spent over $20M over a period of perhaps one year. During this time, the company’s major web site was having daily stability issues and was going down frequently. No code was yet written to address these pressing problems. After a year, the only artifact from the project was a mountain of documentation, which included an architectural design. I was brought in to analyze the technical issues with the web site and servers, which I did in about 1 week of effort. At the end of the week, I produced an 18 point recommendation which included a rewrite of the application. Shortly thereafter, I was retained to lead the rebuilding effort and was shown the design that had been produced by the previous $20M effort. Frankly I was shocked. First of all, it was extremely complicated and over-architected and used bleeding edge (for then) technologies that no one at the company knew how to use. Second, the effort the design must have actually taken was minuscule compared to the mountain of paper it took to produce. I could not believe that they had spent such a large sum of money (lost profit) on what amounted to nothing. Had they implemented the design, it would have been a failure. It would likely have had serious performance issues.. We put a team together consisting of consultants from various firms and paired with employees, and produced our own design. We concentrated on solving the business problem in an efficient manner using technology the company could maintain once the development team was gone. The first thing we did was to shore up the current application so they could function properly. Only then did we begin work on the redesign. The project was completed – design and implementation – in much less than one year, with 1/4 of the price tag of the previous effort. The project was a great success and remained in production until it was upgraded to new technology. I can’t say who the client was, but if you are an IT professional, it is likely you have used the product at one time or another. That story illustrates the need for Just Enough Technology. Technology should drive business, it should enable business. Technology can provide savings or it can provide opportunities that would be difficult to take advantage of without it. That is, if it is used appropriately. When misused it can become an enormous profit-sink that consumes vast amounts of money with little to show for the cost and effort. Software can’t be seen or touched and it can be difficult to appraise a project’s real value or its real cost. Well-meaning tech-types convince business people that they need “the latest and greatest” or bad things will happen. To be fair, most of time I do think their intentions are good, but the truth is the average software architect or developer doesn’t know a thing about the bottom line. They know what is best in a pure sense, but they struggle with what is Good Enough. Since technology seems like witchcraft to many business people, they are hard-pressed to make decisions about how much is too much in regard to software and technology. The outcome many times is overspending and under-delivering. The wrong problem is solved and it is solved in a highly complex manner. Just Enough Technology means providing the right technology to solve the right problem at the right cost. Not too much, not too little. The objectives of the business must be prioritized and kept in mind from concept to design to implementation to maintenance. Every decision made along the way must map to a business objective. Every software requirement must map to a business objective. This is the foundation of Just Enough Technology – clear and concise business objectives. Those objectives drive the requirements, and the requirements drive the design and implementation. Too often this process is short-circuited and a company jumps right to design, resulting in an application that does not provide maximum benefit and probably is over-priced for the needs of the business.

Technorati Tags: Project,CBA,ROI,TCO,Ranck

Is Software Engineering Dead?

Dave Ranck — Sat, 09 Jan 2010 19:23:35 +0000

A new article by Tom Demarco states: I’m gradually coming to the conclusion that software engineering is an idea whose time has come and gone. I still believe it makes excellent sense to engineer software. But that isn’t exactly what software engineering has come to mean.

When I first read this article I was taken aback. As I thought about it, I think I agree for the most part anyway. I found the article on Coding Horror and his thoughts about it as well.

One of the guys that I work with had the following well though out comments:

I like how they use the term “Craftsman” to describe what we do. It actually makes me think, if I were a knight getting ready to invade some castle in the dark ages, would I buy armor from an “Engineer” or a “Craftsman”? Sure I would expect it to have been designed at some point by an engineer, but designs are re-usable. I would think that occasionally someone would come back from wearing a similar, earlier design with specific flaws and maybe have things re-designed by engineers, and those tweaks perfected through practice and applied to other designs. When it comes down to it, those designs and tweaks become patterns and practices. I want my plate folded and shaped by a craftsman who knows those things, but more importantly, how to work with the tools and the different types of metal. One who’s reputation, and thus livelihood, hinged not on how sound a design it was but rather on how well it was executed. One who is meticulous and makes sure no impurities make their way to the critical pieces, making them prone to shatter or crack.

I don’t believe “Software Engineering” is dead, but I wouldn’t want to buy a piece of software from a shop full of them. In theory, they might solve every aspect of the design perfectly, but in reality, it would only work perfect in IE 5.5.3216 running Java 3.2.439. Data integrity might be protected, but how about the user experience. The ones I want writing software for me are the ones that take pride in the experience their software provides and make sure its practical and usable. The ones who have taken the time to master the tools that have been made available to them to assist in their craft.

You get the idea.

~Jeff

Tom Demarco’s article is here

Why Do We Need Software Architects?

Dave Ranck — Sat, 02 Jan 2010 10:07:47 +0000

Another Blast From The Past Article – Originally Published in Sept. 2003

I am a software architect, but I’m not a “Blue Sky” thinker; I’m more of a practical thinker. I asked myself some questions about architects. What is a Software Architect and why do we need them? What do we expect from architects and why not just have a tech lead? Is there real benefit in an architect and are some projects too small for an architect? If so, what qualifies a project as needing an architect?

I believe and practice iterative development techniques and agile methodologies. What I have found, is that even in the agile world, a strong architect can make a project and the lack of architecture (or more properly – architecting) can foil a project’s success. Martin Fowler has written an excellent treatise on Software Architects – Who Needs an Architect? (pdf).

In it, he states:

Architectus Reloadus is the person who makes all the important decisions. The architect does this because a single mind is needed to ensure a system’s conceptual integrity, and perhaps because the architect doesn’t think that the team members are sufficiently skilled to make those decisions. Often, such decisions must be made early on so that everyone else has a plan to follow.

Architectus Oryzus is a different kind of animal (if you can’t guess, try www.nd.edu/~archives/latgramm.htm). This kind of architect must be very aware of what’s going on in the project, looking out for important issues and tackling them before they become a serious problem. When I see an architect like this, the most noticeable part of the work is the intense collaboration. In the morning, the architect programs with a developer, trying to harvest some common locking code. In the afternoon, the architect participates in a requirements session, helping explain to the requirements people the technical consequences of some of their ideas in nontechnical terms — such as development costs.

Do you remember MSF (Microsoft Solutions Framework)? This is a development methodology that was distributed by Microsoft. The Lifecycle methodology was kind of iterative, but on a release cycle, rather than multiple iterations per release ala RUP. It tended (in my mind) toward product development rather than custom software projects or internal IT projects which are quite different from product projects.

What MSF did have is a very strong Team concept that bears close review today. Now they don’t really mention the concept of an Architect in relation to the development team, but they do put great emphasis on a tech lead (who would be doing what I expect an architect to do). The great principle here is that you need at least 3 leaders on a team:

The Project Manager (Program Manager in MSF)
The Tech Lead
The Product Manager

The tech Lead (Architect) takes on the million technical details of a project and the leads the design and development process. The Product Manager is a business representative whose job it is to coordinate the million business details of a project, gather requirements at the business level form stakeholders, and is the business Point of Contact for the project. The Project Manager is responsible for managing schedule, LOE against budget and is the buffer between the Architect (yes I switched terms in mid-stream, good catch) and the Product Manager.

The bottom line is that a strong team needs a good technical mind and a good business mind and a good manager / organizer mind. When the business folks are pushing for more features, the project manager is asking the architect what the impact is and then relaying that back to the business folks. No surprises, scope creep is managed. If a change is scope is really needed, all go into it with eyes wide open.

So then, why not just a tech lead? Because just as the skills required for project management differ from developer skills, architect skills differ somewhat from tech lead skills. A good tech lead certainly has architectural savvy to at least some extent. An architect though is used to always considering the big picture. He or she can step back – and *stay* back, keeping his mind on the larger view. The architect will let the tech lead and developers do their job without micro-management, and yet they are always there to help and advise if needed.

So do all project need a dedicated architect? Yes and no. Certainly on a smaller project the tech lead can function as the architect, but must keep in mind the big picture, the long-term view. Its easy to be inundated with micro-details and miss the larger issues that have great effect over the long haul. On a mid-size or larger project, having an architect (of the type Mr. Fowler describes) can make the difference between overwhelming success and the other alternative.

Take some time to read the article and ponder it. I think it will be more than worth your time. Get the article here.

Risk Management in Requisite Pro

Dave Ranck — Wed, 02 Dec 2009 10:23:01 +0000

Risk Management is an important part of project success. Here is one way to help perform Risk Management using Rational Requisite Pro. Risks are a part of every project. Successful projects successfully manage risks. You can never completely eliminate risk, so it must be dealt with proactively.

From an older article:

Risk management is an important part of Project Management. In my mind it is one of the most important aspects of the development process. Throughout the lifecycle of a project, risks will be discovered that, if not dealt with, can cause the project to fail. By tracking risks and dealing with them head-on and early in the project, the possibility of project success can be greatly enhanced.

Rational Requisite Pro is a good tool for managing requirements, but it has no in-built ability to handle risks. They can be assigned to a requirement as an attribute, but there is no linkage to a Risk List document or Risk Management Plan. I have outlined a simple way to add this capability to Req Pro. to add Risk Management to Req Pro you:

1. Create a requirement of type Risk
2. Create appropriate attributes for the Risk requirement type
3. Create Outlines and Document Types to add you Risk documents to your project
4. Use a view to manage your Risks

There may be other ways to accomplish this within Req Pro, but this is one way that works for us. Follow the steps below to add Risk Management to your project.

Create the Risk Requirement Type

1. Select the project in the Explorer and click File > Properties. The Project Properties dialog box appears.

2. Click Add: The Requirement Type dialog box appears.

3. Type Risk for the Name and a Description (up to 255 characters) for the requirement type.

4. In the Initial Requirement # text box, type the number to be used for the first requirement of the requirement type you are creating or modifying. Requirements are automatically numbered as they are created, starting with the number in this text box. The default number is 1, but you can change the number to any positive integer.

5. If you want to allow requirements of this requirement type to be used in cross-project traceability, select the Allow External Traceability check box.

6. In the Requirement Must Contain text box, type or modify a single word or phrase that must be included in every requirement of this type that is created, up to 32 characters. This box is optional, and is not case-sensitive.

7. In the Requirement Tag Prefix text box, type RISK

8. Select a Requirement Color and a Requirement Style to be used in documents for requirements of this type. The default is blue, Double Underline.

9. Click OK in each dialog box.
Create Risk Attributes

You probably want to create special attributes for your new Risk requirement.I suggest you create at least the following 2 attributes (you can modify existing attributes if you wish instead of creating new ones):

Attribute	Values	Use
Status	Open	Close or defer mitigated risks
	Deferred
	Closed
Ranking	Integer	A ranking of impact on project. Use to create Top Ten List
Mitigation	Text	Strategy for risk mitigation

To create the attributes:

1. Select the project in the Explorer and click File > Properties. The Project Properties dialog box appears.

2. Click the Attributes tab.

3. Select the requirement type from the list.

4. Click Add. The Add Attribute dialog box appears.

5. Type a Label for the new attribute, and select an attribute type in the Type list.

6. For list-type attributes, type the values you want to assign to the value list in the List Values text box. The maximum length for a list value is 32 characters. Order the values in the list as you want them to sort in the Requirement Properties dialog box, Attributes tab. For list-type attributes, you can set the default value using the Default button below the Values per Attribute list.

For entry-type attributes, type a default value in the Default Value list box, if appropriate.

7. To hide attributes of the selected requirement type from all Rational RequisitePro users in a view and in the Requirement Properties dialog box, select the Hidden from display check box.

8. To automatically mark traceability or hierarchical relationships as suspect when the attribute is changed, select the Change affects suspect check box.

9. Click OK to close each dialog box.

Create Outlines

Note: the .dot files list below are standard RUP artifacts. You
may of course use any document you choose.

Copy rup_rskpln.dot to C:\Program Files\Rational\RequisitePro\outlines (or your outline folder location)
Create a new text document with the following 3 lines (each line must end with a carriage return):

RUP Risk Plan
Risk Management Plan and Risk List
rup_rskpln.dot

Save as rup_rskpln.def in the Outlines directory

Copy rup_rsklst.dot to C:\Program Files\Rational\RequisitePro\outlines (or your outline folder location)
Create a new text document with the following 3 lines:

RUP Risk List
Risk List
rup_rsklst.dot

Save as rup_rsklst.def in the Outlines directory

Create Document Types

1. Select the project in the Explorer and click File > Properties. The Project Properties dialog box appears.

2. Click the Document Types tab.

3. Click Add. The Document Type dialog box appears.

4. In the Name text box, type: Risk Management Plan

5. In the Description text box, type: Project Risk List and mitigation plan

6. In the File Extension text box, type: rsk.

7. Select the Risk default requirement type

8. Select the RUP Risk Plan outline

9. Click OK

10. Do the same for Risk List but use the following properties:
Name: Risk List
Description: [Enter your description]
File Extension: RSKL

11. Click OK.

12. Click OK to close the Project Properties dialog box.

You can now add a Risk Management Document and a Risk List to your Risk Package and add Risk requirements.

Create Views

Create a view for Risks. This view will be used to export a list of
risk to be imported into the Risk List document. You should include
those attributes you want in the document and sort on Ranking or
Status and Ranking

To create and maintain a Risk List:

1. Add requirements of type Risk and set attributes appropriately

2. You can set traceability to other requirement types such as Use Cases

3. Add a Risk List document to a package in your project and optionally
a Risk Management Plan document.

4. Export your risk list to your Risk List document
a. Periodically export the view you created for Risks to a Word document.
b. Open the Risk List document and use Insert -> File to insert the exported risk list into your risk list document.

Summary

By creating a requirement of type Risk, you can use Requisite Pro to trace risks to other requirements. In this way, you can always know what requirements are affected by certain risks. You can also maintain your risks in the Req Pro database and semi-automatically update your risk list document.

Using Rational XDE with Visual Studio .Net

Dave Ranck — Sun, 15 Nov 2009 06:57:05 +0000

I have not been a great fan of reverse engineering tools in general. When I was creating applications in years ago, I held great hope for Visual Modeler. I do strongly believe in providing adequate documentation for an application and I most certainly value implementing an appropriate design phase during a project’s lifecycle. The tools available for accomplishing this have been sorely lacking in key areas, in my opinion.

What makes a documentation / design tool a good one? Well, seamless integration into the development process is one quality that is important to me. I detest having to input the same information more than once. That is one of the greatest strong points of automation. I’ve designed applications to automate workflow processes and share information between systems using tools that did not provide a solid way to do this with the development process.

To be useful to me, a design tool or documentation tool has to be powerful enough to meet the 80 / 20 rule of providing 80% of the features I need. At the same time it has to do this without placing a heavy burden on the development team or lifecycle. It also needs to be adaptable for varying project sizes and timeframes. What is appropriate for a project with a team of 20 developers with a timeframe of 12 months is not necessarily appropriate for a project with a team of 3 and a timeframe of 3 months. Both projects require proper design and documentation, but the relative cost or weight of this design / documentation activities must be correspondingly lower for smaller projects. This is simply a case of the law of diminishing returns.

Because of the limitations of the tools of the time, I tended to use more manual methods to achieve design and documentation goals. I even automated some of the documentation tasks with my own add-in for VB 5 & 6. For design, I found VM to be clunky to use and lacking certain key features found in the full version of Rational Rose. Rose, on the other hand I found to be overkill (and expensive) for any but the larger projects. The result was that design was handled in a separate, readily available application such as Visio.

All this has now changed since I’ve been using Rational XDE with .Net. I was introduced to XDE as a plugin for Eclipse, the open source Java IDE at a software conference. My prior prejudices conspired to hinder me from thoroughly investigating XDE as a tool to include in my Java toolkit. Note: While I have significant experience designing J2EE applications, I now concentrate on .Net – perhaps that should be the subject of a separate article. With XDE, I’ve found what is for me a perfect combination of power and flexibility for any size project, even small projects.

What is XDE?

Rational XDE is a graphical component modeling and development tool that uses the industry-standard Unified Modeling Language (UML). It integrates tightly with VS.Net and allows seamless code generation and reverse engineering. It is both powerful and flexible, allowing the architect to choose how much of its power to use on any given project. XDE allows you to create classes in UML, include them in various UML models such as Sequence Models and Class Diagrams. Because this inclusion is in reality a link to a single instance of a class, updates to that class are reflected in all models that use the class.

XDE in Visual Studio

Since XDE functions as an extension of the VS IDE, it is tightly integrated into the design / development workflow and project structure. Models created for the classes in a project, stay with the project as a part of the project hierarchy. This creates a cohesiveness that tends toward a transparency between XDE and VS. You forget that you are using a 3rd party tool and begin to believe that XDE is an integral part of VS. I quickly found myself dependent on XDE for day to day tasks over the lifecycle of a project.

XDE allows you to create Analysis Models that are high level abstractions of the system. Typically, these types of models are not linked directly to code. They exist entirely separate from the code. This allows the creation of high level architectural overviews as well as the realization of Use Case models to validate the basic design before implementation begins. At this level XDE functions as a very good drawing tool, but the models are linked to the VS project, keeping the project and documentation together.

Once you get to the Elaboration and Construction phases the fun really begins! XDE allows you to work the way you want to. Do you want to create your models first and then generate the stub code for all of your classes? Would you rather create the classes in C# and then generate the UML class models from the code? XDE works equally well either way and I find myself doing both depending on the task at hand. This is where I think XDE shines. Code generation and reverse engineering work well in XDE. It is a straightforward process to keep the code and models in synch. One of the best parts is the XDE uses reflection to create classes from the code. It does not parse the code window as other tools have done in the past. There is no extra code or comments added to the .cs files for XDE to work its magic.

Using XDE with a development team

XDE allows the separation of roles on a development to enforce good design and standardization. One senior person can be given the application level design tasks to create a consistent and coherent architecture. At the same time, construction level design can be handled by the architect or handled by the individual developers of a component of the system. Because of the powerful reverse engineering tools, the architect can always keep the model up to date. Better still, developers can enhance the models created by the architect with the details of implementation. Following this practice allows developers to acquire design skills and encourage thinking before coding. The architect can review models before implementation if desired to enforce project goals and guidelines.

Project Managers and Business analysts can create their Use Case models directly in XDE. The architect can later realize these Use Cases with class diagrams and other models. This creates a seamless end to end project lifecycle structure from inception to construction. Alternately, Use Cases can be imported from other Rational Tools if desired.

Keep in mind that, as with the Rational Unified Process, you don’t have to use all of XDE on every project! For example, on a recent project the workflow went something like this:
The business analyst created Use Cases using the RUP Word templates – no Rational Toolset. This level of automation was fine for this project. There was no clear win to introduce the learning curve and overhead of the full rational Toolset. From the Use Cases, I created Analysis Models to design the overall architecture of individual application components and to validate that the Use Cases were being realized properly. Once a component’s design was validated and realized at a high level, I created separate code-level models and generated the stub code from the models. After the construction of a component was complete or reached a significant milestone, I reverse engineered the models to update the UML. As the project progressed, some of the construction level design tasks could be handed off to the development team. Critical components were still designed primarily by the project architect, but by distributing the responsibility for component design, a more efficient workflow could be achieved.

Conclusion

I have found XDE to be a very valuable addition to the VS toolkit and will find it awkward to work without it on future projects. Unfortunately, because of the cost of XDE, I may have to forego all the benefits of XDE in some projects. A license for XDE runs from approximately $1600 TO $5000 Depending on the version chosen. Different versions provide differing levels of functionality such as database modeling and reverse engineering and visual tracing. The relatively high cost of this add-on significantly reduces its application to smaller projects and companies.

XDE is a great tool and if the project budget can afford it, I highly recommend employing it for design and documentation tasks. For many projects, all the bells and whistles may not be needed and the basic version will provide more functionality than is required. For larger projects, I would insist on XDE’s inclusion in the development tool set.

A Programmer’s Bill of Rights?

Dave Ranck — Sun, 01 Nov 2009 12:09:20 +0000

Here’s a link to good post that talks about how companies can enhance developer productivity with some small investments in things like dual monitors. I just reread this article after finding it over a year ago. I am diligently trying to move our own department towards the things listed in the article, though some items, such as dual monitors, may be difficult for us given the current economic climate. We developers understand experientially how these things help our productivity, but is not always easy to communicate these truths to management.

It is difficult for developers to understand why a company might resist making changes like these, given the tangible benefits of these practices. Monitors for example are cheap compared to the cost of a programmer’s time. I joke with my team, by telling them: “Your problem is that you think logically” In a lrage company, the bucket the money comes out of is almost more important than the actual cost.
Here’s an article on CodingHorror.com that puts forth a Programmer’s Bill of Rights. I just reread this after finding it a year or so ago. Some of the ideas here make good sense. There are concrete things that can be instrumented that will increase the effectiveness and therefore the cost-effectiveness of a development team.

We programmers are often viewed as overhead. The company pays the same amount on a monthly basis for our services regardless of how long it takes us to perform our development tasks.

The last line of the article states “And remember: you can either change your company, or you can change your company.” Hmm, things may have changed a bit since this was written a few years back. That isn’t to say that we don’t have the required influence to initiate change, we just have to use it bit more wisely. Demanding change probably won’t work. We must strive to show tangible, not theoretical benefits whenever possible. A couple of things happened here that may have helped our cause, and perhaps you can leverage the same ideas to your benefit. First, my team started requesting to work from home more often because they have better equipment at home. Second, one of the guys bought a new wide screen monitor and brought it into work so he could be more productive. He had to take it home, because company policy doesn’t allow connecting personal equipment, but the point was made. By the way, these actions weren’t part of a planned effort. It was completely organic.

So read the Programmer’s Bill of Rights and see what you can do to influence its adoption at your place of work.

Link: Programmer’s Bill of Rights