Hard Drive Cloning

TL;DR

Stuff that didn't work:

• Bootable USB drive with cloning software on it
• Samsung disk cloning software
• HDClone
• MiniTool Partition Wizard 12.0 (Demo)

Stuff that worked:

• Macrium Reflect
• Macrorit Partition Expert v5.3.9

-------------------------------------

A friend had some computer trouble. Lots of errors popping up on startup, applications refuse to update, warning messages about failed OS updates, etc. All of which is due to a good configuration idea that fails in practice. He had a 128 GB SSD and a 1 TB HD. Ideally, only the OS would be installed on the SSD and everything else would be saved on the HD. But that didn't happen. The software defaults all pointed at the SSD so when he installed an application, downloaded music, uploaded photos, etc it all went to the SSD. Even if he would have been doing it all the "right" way, the Windows 10 footprint is quite large and the 128 GB SSD would probably have been getting crowded.

I offered to clone his 128 GB SSD onto a 1 TB SSD to resolve the root problem.

Option #1:

I came prepared with a bootable USB drive with disk cloning software on it.  But his computer refused to boot from the USB port. In fact, his computer wouldn't even display the BIOS settings unless a hard drive was connected. Weird.

Option #2:

I had some Samsung disk cloning software from a previous purchase. I cleared some spaced on this computer and installed it. It refused to acknowledge the Crucial SSD that I was upgrading to.

Option #3:

Ran HDClone 8 (Free Edition) to clone to the new drive. There is a popup on application startup that warns that the program has been intentionally hobbled to run slow unless you pay for the "enterprise" edition. Cloning to the new drive took one hour and 15 minutes. When it finished it warned that there had been numerous errors and claimed that the source drive was corrupt. I tried booting with the new SSD and as expected it wouldn't boot. Worse yet, Windows couldn't format the disk and Macrium Reflect would freeze trying to read the drive.

At this point, I believed the 1TB SSD was bad and replaced it with a Sandisk 980 MB SSD.

Option #4:

More than two hours had gone into this project and I was getting a little desperate to speed things up. I put Clonezilla on my USB drive and tried to boot from it. Once again, the computer refused to boot from USB.

Option #5:

I accepted that this would be a slow process and used my own laptop to image the 128 GB SSD using Macrium Reflect. My laptop is a cheap thing that was intended only for watching DVDs, Netflix, and Internet browsing. It only has USB 2.0 ports. However, there is something to be said for the adage, "Slow and stead wins the race."

Imaging the drive took approximately 1 hour. That tells you that the HDClone 8 (free edition) artificially slows things down to USB 2.0 speed. Next, I restored the image to the 980 MB SSD. Grrrr! There is no option to adjust the partition sizes. I tried several pieces of software to resize the partitions but they would stop just short of doing anything then say, "You have to purchase the professional version of this software to perform this action." Eventually, I found Macrorit Partition Expert v5.3.9 which allowed me to resize the partitions and fully utilize the SSD.

Macrorit Partition Expert v5.3.9 also was able to wipe the Crucial 1 TB SSD that had been fubar'd in option #3. It appears that there is nothing wrong with the drive.

I put everything back together and my friend's computer is working well. I left it happily downloading and installing the multiple gigabytes of Windows updates that it was behind on.

Avoid Standing Waves

One of the odd side-effects of keeping your plans up-to-date is the standing wave. In this situation, you always plan to update your plans over the next few weeks. Since projects that are behind schedule tend to get further behind schedule, this "update the plan soon" strategy requires larger and larger resources to be applied over the next few weeks. The wave gets larger and larger with no corrective action taken. Rescheduling and replanning in general require action, not just promises that things will be fixed soon. Just because you are only a few days behind, don't put off updating the plan. All projects fall behind one day at a time.

Reference:

Brooks, F., The Mythical Man-Month, Reading, MA: Addison-Wesley, 1975.

Keep Your Plan Up-to-date

You must plan a software project; however, having an out-of-date plan is even worse than having no plan at all. When you have no plan, you know you are out of control. When you have an out-of-date plan, you may naively think you are under control. So whenever circumstances change, update your plan. Such circumstances include changes to the requirements, a schedule slippage, a change in direction, finding excessive errors, or any deviation from the original conditions.

A well-written plan should enumerate the risks, the warning signs that the potential risk is becoming a threat, and contingency plans to put into place to reduce the threat. As a project progresses and predicted risks become threats, the contingency plans are implemented and the project plan is updated. The real challenge occurs when unforeseen changes occur. For these times, one often needs to replan the remainder of a project in its entirety, with new assumptions, new risks, new contingency plans, new schedules, new milestones, and so on.

Reference:

Reifer, D., "The Nature of Software Management: A Primer," Tutorial: Software Management, Washington, DC: IEEE Computer Society Press, 1986.

Quantify Requirements

All to often terms such as "fast," "responsive," and "extensible" are listed as software product requirements. Software architects often spend a lot of time helping product owners turn these desires into objective requirements. We do this by asking a lot of questions: How often? How many in what period? Increasing or decreasing at what rate?

It is a process that most product owners find maddening. Which is why it is important to explain that an exact answer is not expected. In fact, an exact answer would be a little worrying and I'd want to know how they got it. It is that process of how to get quantitative criteria that often needs to be explained and planned for. Finding ranges for quantitative requirements and checking against them is a time-consuming and expensive process. If no one wants to spend the time, effort, and money to do so then it reveals that the requirement isn't actually needed.

Focus your efforts on the parts of the system that stakeholders actually consider worth paying for.

Plan A Project In Detail

Every software project needs a plan. The level of detail should be appropriate for the size and complexity of the project. At an absolute minimum, you will need:

• A PERT chart showing the interdependencies among tasks.
• A GANTT chart showing when activity will be underway on each task.
• A list of realistic milestones (based on previous projects).
• A set of standards for writing documentation and code.
• An allocation of people to various tasks.

As projects increase in complexity, each of these requirements becomes more detailed and more complex, and other documentation becomes necessary. A project without a plan is out of control before it even starts. As the Cheshire Cat said to Alice in Wonderland, "If you don't know where you are going, any road will get you there!"

Reference:

Glaser, G., "Managing Projects in the Computer Industry," IEEE Computer, October 1984.

Allocate Appropriate Resources

Artificially constrained schedules and inappropriate budgets will doom a project regardless of the quality of the people or the availability of tools, languages, and process.

If you try to compress either schedule or budget, the engineers working on the project will not work efficiently, there will be no wiggle room when the inevitable slippage occurs, morale will suffer, and the project will probably cost more than what would otherwise be considered reasonable anyway.

In short, tightening a schedule or budget to land a contract or to get stakeholder sign-off will only ensure your failure to deliver. The goal isn't to get project approval. The goal is to get approval for a project that can actually succeed.


Reference:
DeMarco, T., "Why Does Software Cost So Much?" IEEE Software, March 1993.

Minor Underestimates Are Not Always Bad

Assuming morale has not been diminished, members of a project that is perceived as slightly behind schedule will tend to work hard at catching up, thus increasing productivity. Similarly, members of a project that is perceived as slightly ahead of schedule often take vacation days, work less hours, read their email longer, and ease up in other ways, thus decreasing productivity. In other words, the cost estimation itself will affect the project outcome. Any specific project may expend less resources if it is slightly underestimated than if it is slightly overestimated.

Be careful, though! If project members believe that the schedule is ridiculously underestimated or that estimates are underestimated on purpose, then morale and productivity will decrease. Worse still, you, as a manager, might start to gain a reputation of being incompetent, manipulative, or both. If that happens then project members will begin to perceive all estimates, even good ones, as bad.

As long as a minor underestimate is a natural occurrence then there is no need to worry that it'll effect the schedule. Team productivity has a certain amount of flexibility to compensate as long as there are minor overestimates to balance things out.


Reference:
Abdel-Hamid, T., and Madnick, S., "Impact on Schedule Estimation on Software Project Behavior," IEEE Software, July 1986.

Reassess Schedules Regularly

Schedules are usually set at the beginning of a project. These include intermediate deadlines as well as the product delivery deadline. As each phase is completed, the schedule must be reassessed. A behind-schedule project rarely recovers during subsequent phases. Thus, a project that is, for example, one month late at completion of design will be at least one month late for delivery. In most cases adding or removing people will only delay the project further. The most common technique is not to change the product delivery date. (After all, we don't want to disappoint the customer just yet; they might stop paying.) As each intermediate milestone is missed by an increasing amount of time, the time allocated to testing is reduced more and more. At the end, one of two situations is inevitable:

1. The product is shipped without the necessary quality.
2. The customer is notified of a very large schedule slip very late in the project.

Neither is acceptable. As a manager, your responsibility is to prevent disasters.

Instead, establish a working relationship with customers and/or management levels above you. Report every possible date change (usually a slip) and discuss the alternative strategies for overcoming them. The Agile methodology is very keen to cut out features in order to hit delivery deadlines. Only early intervention and involvement by all parties can prevent slippage escalation.

Reference:

Shore, J., Warden, S., The Art of Agile Development, O'Reilly Media, 2008.

Gilb, T., Principles of Software Engineering Management, Reading, MA: Addison-Wesley, 1988.

Believe in the Schedule

Probability of Project Success

Once a feasible schedule is established and appropriate resources allocated, all parties must believe the schedule. Engineers will not succeed in meeting a schedule if they don't believe it is realistic. The probability of success is more a function of faith in the schedule than its realism

The best advice is to have engineers set schedules. Unfortunately, this is not always possible. The second best advice is to involve engineers in the tough trade-offs that occur between functionality, schedule, and project abandonment. Few engineers would rather lose their job because a project is canceled than strive to meet a tough schedule.


Reference:
Lederer, A., and Prasad, J., "Nine Management Guidelines for Better Cost Estimating," Communications of the ACM, February 1992.

Know Before You Count

"Know before you count" is a software development management principle simply stated by Gerald Weinberg as, "Before you can count anything, you've got to know something." He is talking about the many people who count things in software but don't know what they are counting. He provides a great example. We have data concerning what percentage of the software industry is involved with maintenance rather than development. But can we recognize maintenance? Is a "new" development that completely replaces an existing system considered maintenance or development? Is a "modification" to an existing system that doubles current functionality and removes 95 percent of old functionality considered maintenance or development?

When selecting metrics for your project, make sure that what you are measuring relates to what you are trying to achieve. This often entails using multiple metrics. Remember: Even if everybody is measuring something one way, that way is not automatically right for you. Think about your metrics. Since everything can be observed (and in most cases measured), carefully select what you want to observe (and measure).


References:
Stark, G., Durst, R., and Vowell, C., "Using Metrics in Management Decision-Making," IEEE Computer, September 1994.

Weinberg, G., Rethinking Systems Analysis and Design, New York: Dorset House, 1988.