The starting point for BRender was a sequence of software rendering experiments that grew from 'never doing it like our hand coded asm real mode x86 renderers ever again'. There were various diversions, eg: an achingly beautiful plane sweep that only rendered the visible parts of each output scanline, whilst murdering the cache so comprehensively that there are likely still lines waiting to be filled even now. Fortunately, to get the FX Fighter team going with something stable whilst debugging continued, I knocked up a Z buffer implementation, and was given a sharp lesson on caching when it blew all the previous attempts away (notably with consistency of performance).
Arriving at this point we figured there might be a product in it and looking at our own interaction with other libraries, it was clear that a manual was key to this. If I remember correctly, the API was a negotiation between myself proposing designs, and Crosbie Fitch documenting it - pushing back with ways to make things easier to explain.
It worked out very well, and we took it into later Argonaut hardware projects. The hardware guys had enough tools to do frame capture and replay from various games/apps at a low level, so were not desperate for a full software stack. The clients had very particular views about how APIs should look, depending on planned uses, in house style, compatibility etc. We would negotiate the API documentation back and forth - including lots of sample code.
This sample code was important, (and BRender would have benefited from more of this). I took lots of real use cases, then wrote proper code to implement them against the proposed APIs and included them in the docs as tutorial and example code. Importantly - they were a representative sampling of the anticipated uses (not just the easy ones), they were not 'handwavy' and included all appropriate resource management and error handling, and they had to read well on the page. As the API negotiation continued, so the examples and tutorials got updated.
This process also had the benefit that we only started investing in client specific software development once the project had got enough momentum (typically committing hardware NRE).
These days I am always being rushed through sprints barely knowing what is going on.
What you described sounds like a wonderful way to actually engineer a great API.
Whilst the official progress is top down, the duck's feet are working hard feeling along the bottom to check for obstacles.
Just because you say you want it in 2 weeks does not make it so. Don't over promise, you will be severely disappointed. Software breaks, it does not care for deadlines.
The thing I was talking about was larger scale projects like the ones mentioned by the author (of the sort I work on at my day job) where you have teams of stakeholders and outside influence combined with a desire to release rapidly in an iterative form.
Software these days is just done differently in those contexts...we can't slow down enough to do what was detailed above...I just wish the world was sorted in a way or slowed down enough to do REAL engineering.
The code was mostly C, with some protected mode x86 for inner loops. Prior to that point, all our PC games had been real mode x86- and BRender was a result of moving away from that.
I dug into the released BRender source until I found the inner loops, then I "Nope!"'d all the way out and remembered why I never went back to assembler.
Thanks for the memories. I'm glad the code survived all these years until it could be released.
a more elegant weapon, from a more civilized age, may the forth be with you ;)
Very evocative writing, I love it.
If it is, "Hello Sam!"
I still remember winning the 'Bog Roll d'Or' for being last man standing in the Phall eating competition.
Oh, and the Yaohan Plaza (aka Oriental City, Hendon).
You start e.g. with a press release and then make your way backwards to the user stories and backlog.
It's a very useful approach to think big and focus on the problem instead of the many little issues that need to be solved.
The problem is that programming is still knowledge work. That means you can not specify everything beforehand without doing the actual work. (Like writing a novel, which can not specified before.) The solution would imho be a good balance between description the big picture/desired result (good) and spec'ing out every little detail and screen in advance (bad).
It was pitched as something like "wishful thinking programming" IIRC. First you write the highest-level "business logic" code that you want to write with made-up constructs that have no implementation, then only once you've established that it feels good to write code using those constructs do you implement them.
I remember this also being the same approach that was used in a CPU-building course I took (NAND 2 Tetris): start with the instruction set, then implement it.
Oftentimes in the book, they will write out a function with reliance on a variety of other functions that haven't been written yet, but which show a blissfully declarative outline of exactly what the function does. Then you go and write the sub-functions.
Looking at the code after is quite nice, but it takes a bit to wrap your head around writing large swaths of code that can't run -- especially when you're used to writing REPL-driven code and consistently checking/"testing" it
I think you should consider writing unit tests before coding but then delete them and then write regression tests after. Though, haven't tried this approach yet.
It's been very pleasant, and allowed me to make good sense of what I was doing and where I was going.
That means you have to study the old code, which is of course poorly documented and probably buggy; and then try to reproduce it in a sane way.
- https://github.com/ruby/ruby.wasm (compile Ruby to WASM)
- https://mame.github.io/emruby/ (example of Ruby compiled to WASM)
- https://opalrb.com/ (compile a subset of Ruby to JS)
This requires downloading several MB of code (and then caching it in-browser) so would be ideal for internal-only stuff.
(Part of my thinking with this solution is to broadcast "you are asking me to do something that requires a solution this complex to wrangle the problem space effectively" to try to fend off similar inanity in the future, admittedly, perhaps I'm being a bit optimistic/unrealistic heh.)
I guess perhaps you are working with some very obfuscated code, still if you are black box profiling code it might make sense to crack open that box as much as possible. Unless what you are working with is DRM-level "performs like cow dung in a blender" horrifically inefficient, I can't imagine it is obfuscated that badly.
At any rate, hopefully you are paid well for it, reverse engineering is difficult, to say the least.
I decompiled the app, documented the UI and which variable is what. Rewrote the whole app. It was quite painful but good learning experience. I would love to do another one.
1: https://tom.preston-werner.com/2010/08/23/readme-driven-deve...
Actually implementing something is left to the final 30% of a project. One must first bore themselves to death with design and documentation before a single line of code is written.
This really only works if you have done the same or something very very similar before and so you have practically no unknowns. Notice that the developer who did that commented above that they had already done similar work at the past.
Also related this quote about how Joe Armstrong (of Erlang fame) approached problems (from [0]):
> Joe wrote amazingly simple programs and he did so in a peculiar way. First he wrote down the program any old way just to get it out of his head. Then once it worked he would then immediately create a new directory program2 and write it again. He would repeat this process five or six times (program5, program6, ...) and each time he would understand the problem a little better and sense which parts of the program were essential enough to re-type. He thought this was the most natural thing in the world: of course you throw away the first few implementations, you didn't understand the problem when you wrote those!
I'm incredibly impressed with programmers that can visualize a large program and the end product actually resembles what they originally envisioned. That is a gift.