I'm hoping this will be interesting and perhaps useful, even if it looks like a rather negative take. I'm interested to hear from others too.

I should just note first, that a project which goes wrong is also a learning experience, so long as there's a followup project which does a bit better.

I think we all like it when projects go right, and we like it when someone can manage a series of projects, but fairly often projects go wrong, and so that's something worth trying to avoid. Here are some things, then, to avoid, which can result in a project never finishing, or never working, or never being followed up with a successor project.

- the project was taking too long and making too little progress
- the project became too expensive
- the thing kind of worked but was unreliable
- there were too many choices and I couldn't decide on the right way to go
- I had a bigger better idea so I switched tracks
- I didn't have the tools to investigate the problem
- I'd done my design and then couldn't get hold of the parts I wanted
- I sent a PCB design off for manufacture and then discovered an error, and that happened several times
- it was too difficult to route all the signals on the PCB
- I finished the hardware but no-one stepped up to write the software
- I wanted to finalise the software design before building any hardware
- I kept making fixes but never pinned down where the problem was
- I couldn't get a consensus on the right design to build
- I completely messed up the soldering
- the software tools are unreliable and incomprehensible

I'm no great completer-finisher myself, but I think there some tactics which can help
- keep things tidy - workspace, notebooks, boxes of bits
- proceed in small achievable steps
- ask for advice, and when you do, describe your situation and your challenge carefully
- sketch out a plan of attack
- think of this project as one of a series of increasingly ambitious projects
- keep things simple
- change only one thing at a time and take notes of what you tried and what you saw
- finish one thing before starting another
- gather your resources before you start
- build an existing working design before building your own design
- study other similar successful projects
- put some regular time aside to dedicate to your project
- wait until you have the energy and time before trying difficult things
- take a break when you're frustrated

Great post, Ed. One thing I will add as a complete neophyte: debug your assumptions! When something goes wrong in your project, you don't just want to fix the problem, but also fix the thought process that led you to making a mistake, so that you can learn from it.

I like to keep copious notes and make “predictions” of how a design decision will pan out; then, when I try it out in practice, I go back and compare my expectations with reality to reflect on how correct my intuition was. Most of the time (especially when starting out on something completely new), I'm hilariously wrong, but failure is a great teacher—if you know how to fail well and don't get too hung up on the fact that things didn't go according to plan.

Ed, many of your points remind me of the old adage of fail fast, fail cheap, and apply what you learn to the next iteration. We're lucky to live in a time where many electronics projects can be designed and built quickly and inexpensively (you can get a PCB built and shipped for less than the cost of a movie ticket!), whereas time is always in short supply.

A final thought: I find it very useful to always have more than one project on the go. As long as you don't start so many things that you get too distracted, it's good to have something else to fall back on when you get stuck or frustrated, or while you wait for, say, parts to be delivered or a new PCB to be manufactured.

Love that quote. I would add "never plan to get it right the first time". That is the heart of the Spiral Development Cycle, aka Cinnamon Roll Development Cycle.
Bill

Great post, Ed.

On that topic, I've been reading "Designing Electronics that Work", https://designingelectronics.com/ (non-affiliated with the author). I can't remember if it was here or on Reddit that I saw the recommendation, but I find it is a good resource.

_________________
BB816 Computer YouTube series

Thanks for the positive comments!

There is a famous 'how to ask for help' article online but I find the tone a bit snarky. Nonetheless, I think two useful things to have would be concise, readable, and friendly versions of
- how to debug
- how to ask for help

I think it's crucially important to have a way to doubt yourself (without losing confidence!)
- what don't I know, that's needed here
- what do I think I know, which isn't true here

For example, one might not know about ground bounce, or one might think the address bus is correctly connected.

One pitfall in debugging, I think, is to keep iterating on "but I know all this is correct, it just doesn't work." If it doesn't work, then something's wrong, so something hasn't yet been checked carefully enough.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Closely related is the following. Someone has a few theories about what the trouble may be, and wants to zero in on the problem by ruling out those theories which have been disproven.

That's all good, of course, but at the same time you need to take your own conclusions with a grain of salt.

When you've hit a dead end and the whole situation seems impossible, sometimes you need to retrace your steps mentally, and reconsider the times you said yourself, "Well, it can't be <whatever>."

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

It’s interesting how many of those problems apply to Babbage’s Difference Engine and Analytical Engine.

_________________
I like it when things smoke.
Blog – Zolatron 64 project

Ha ha! Excellent observation! We have ourselves a case study...

One of the problems with hobby projects is that we don't have a lot of constraints on requirements (or schedule either), so there are so many more options, and it takes time to narrow them down.

The main thing that goes wrong for me is if I create a PCB and don't get something working out of it. On the other hand I have one PCB that has no corrections applied, a rarity that I am quite surprised by. Most of my PCB's are working, but have a few patch wires to correct minor mistakes. It does have a CPLD on there, which does give some scope for fixing errors. My next PCB is sitting on my desk unfinished because, firstly it is a bit experimental, and secondly I got the pinout of the serial chip completely wrong and it's left me a bit discouraged. There's not much use in a 65C816 system with no I/O. But it is salvageable by connecting the expansion connector to a breadboard and a new serial circuit.

The thing with that last board is that I'm trying to do two completely new things on one board. I feel like it would be a good rule of thumb to only do one completely new thing with each PCB revision. At least then you should know where the problems will be and you can trust most of the design. That's a corollary, or maybe just a restatement of BigEd's suggestion to "proceed in small steps"

My C640 project is the first hobby project that I feel has been successful. In the past I've tended to make some progress, get to a hard bit, and then get distracted by something else.

This one, however, is big enough that the "something else" can be another sub-project. When I get frustrated by the lack of progress on sprites, I can switch to getting BASIC to run. Or work on that long-standing memory timing issue. Or chip away at the compiler for the language I want to use on it.

When you find a bug, write it down. You don't always have to fix it right away (you do if it's blocking anything from working at all, but in a large project those are the exceptions). Make a note of it, and then it can safely leave your brain and let you continue with what you were doing. It'll also give you something to come back to when you need to change gears.

When you think of an exciting new thing to add, write it down. It doesn't have to be done now.

When I fix a bug or implement a feature, I mark it "done" and move it to the top of the file. Having a long list of things I've already achieved is reassuring when I feel overwhelmed by the mountain of work that needs to be done. I've already built a bigger mountain.

Ed, I was reading that list, and quite a few tagged me!

Besides 6502 projects, I have been coding for many years. And what helps the most is "small victories". A ton of them. Getting some piece of code to display a sprite on the screen, victory! Read in keyboard values and now move that sprite around the screen, victory! Control the timing of the program and correctly animate the spite, victory! A series of these will keep pushing you to more success. Always save your previous work, in case your latest attempt failed, you can fall back on a working model.

The biggest leap here in 6502-land for me was the lack of small victories. When designing the schematic, the board, the demo code... it is all a one-shot deal. Have your board printed and wait a week or whatever, solder all the pieces, and you end up with a brick. Now what? So much time, so much effort, and that small victory didn't happen.

But when it does work, that's a BIG victory!

Thanks everyone!

Chad

Thanks Chad, and thanks everyone else upthread - and everyone who helps with supporting newbies and troubleshooting efforts here. A second head makes such a difference.

I've previously suggested working on a project with 80% probability of success. This way you'll spend 60% of your time using familiar skills, 60% of your time on known unknowns and 60% of your time on unknown unknowns. Yes, that's 180% of the estimated time. Plan accordingly.

Know when to drop a project. Don't get distracted with too many projects. I agree with John West that work on software should fit around the longer lead times of hardware. I also agree with Joel Spolsky that a task which is not divided smaller than two days (16 hours) is effectively infinite. In a formal environment, it is essential to have weekly reports, verbal or written.

In the case of hardware, I've found a curious case where it is possible to retrospectively divide a project. After designing a PCB, sending a PCB to manufacturing, receiving examples of the design, it remains possible to divide the task into two or more smaller pieces. For my computer design, I strongly considered four or more iterations prior to manufacture. However, given that it is possible to test ROM, RAM and I/O in stages, two iterations were sufficient. The first iteration has all non-essential features removed. The second iteration has a more complicated memory map and clock stretching.

In general, if you haven't been chunking tasks, it is possible to start retrospectively.



I cite Charles Babbage's Analytical Engine as an early example of the second system effect. Adam Osborne is a more recent example. I worked backwards from version two partly to avoid these problems. But don't worry because version three will be awesome! Actually, I highly recommend a technique of feature triage: this version, next version, or some distant future version. This technique never rejects a feature. It defers wild features until they are implemented or dropped.



Hobby projects and commercial projects both have limitations. A commercial project typically has a fixed deadline and the fixed constraint of downward compatibility. Although, for a 1980s design which can be fully understood by one person, downward compatibility isn't too onerous. For a hobby project with no deadline and the ability to discard your own constraints, we want it to be better for the simple reason that we have the luxury of making it better. Too easily, that leads to "analysis paralysis".



For hardware or software, there is minimal consequence for adding multiple, unrelated, non-critical functions in one revision. However, if you have two or more mutual, critical functions then catastrophic failure is increasingly more likely. A technique which BigDumbDinosaur uses effectively is to keep the software unchanged when changing the hardware and to keep the hardware unchanged when changing the software. Even within this, BigDumbDinosaur makes a spread bet where some changes are almost guaranteed to succeed while others have decreasing probability of success. Indeed, it may be worthwhile to confirm failure empirically to see if it is a bad assumption.



When I joined the 6502 Forum, I didn't intend to make hardware but after reading an archive heavily skewed towards hardware, I've gone native. My initial impression of patch wires was unmitigated bodging. This was replaced by an impression of modestly and proportionately over-extending ability. After my own failure, my impression became "proof-reading is most effective after publication". I now view a PCB as a very specialized perfboard with suggested wiring. The suggestions may or may not be accurate.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!