The Great AI Arbitrage: making a killing before your client wises up

There is a silent heist happening in the billable hours of every major software agency. We’ve entered a Golden Hour - a brief, high-stakes arbitrage window where the cost of production has cratered, but the price tag remains frozen in 2022.

History is littered with these windows. They are defined by Knowledge Asymmetry: the gap between what a client thinks it takes to build a product and the time it actually takes, using a magical new tech.

We are living through the Agentic AI version of this playbook. In the time it takes a client to finish a discovery meeting on Teams, an agent has already drafted, tested, and hallucinated its way through the first 40% of the codebase. The agency is billing for the month; the machine finished before the coffee got cold.

Here are the most iconic historical parallels to the Great AI Arbitrage:

1. The Gutenberg Gap: The Scribe vs The Printing Press

In the 1450s, a hand-copied Bible took a scribe about a year to complete. The price reflected 12 months of high-level professional labor.

The Tech: Johannes Gutenberg’s movable type press.

The Arbitrage: Early printers were notorious for trying to make their books look exactly like hand-copied manuscripts. They used the same ligatures, the same layouts, and sometimes even had artists hand-illuminate the first letters of a printed page. They charged scribe prices for a product that was essentially mass-produced. 

2. The Master Gunsmith vs Interchangeable Parts

In the early 1800s, if a part of your rifle broke, a master gunsmith had to hand-forge a unique replacement. You paid for that master craftsmanship.

The Tech: The transition to interchangeable parts (mass production); machines began stamping out identical components.

The Arbitrage: Government contractors and factory owners keep billing for "fitting and filing" (the manual labor of a master gunsmith) long after the parts were being stamped out by low-skill laborers using jigs. 

3. The Master Machinist vs CNC Programming

The CNC (Computer Numerical Control) lathe transition of machine shops during the 1980s is the most direct ancestor to the Agentic AI shift in software development. It wasn't just a change in tools; it was a total transfer of power and a massive, hidden profit engine.

Here is the deeper breakdown of what happened:

The "De-skilling" of the Master Machinist

Before CNC, a master machinist was a craftsman with specific knowledge. They didn't just turn handles on the lathe; they had "the feel" for how metal reacted to heat and speed. This was deep, learned knowledge - it couldn't be easily written down or taught to someone else, and it gave those machinists immense leverage over shop owners.

• The Tech: G-code and microprocessors made that deep knowledge redundant. The new machine could replay its tool-paths perfectly every time, regardless of whether the operator understood the physics of the cut.

• The Arbitrage: Shop owners realized they could buy one $80,000 CNC lathe (the price of about 12 manual lathes in 1981) and hire a "button-pusher" CNC operator at 40% of the Master Machinist's wage to run it.

• The AI Parallel: Today, an agency can use Claude Code to replace a team of senior developer SMEs on a complex legacy project with one AI "prompt-pusher" keeping a zombie legacy project on life support.

The "Ghost Labor" Billing Model

This is where the real money was made. In the 1980s, the market rate for precision machining was anchored to the labor of the machinist.

• The Old Reality: If a complex aerospace part took 10 hours to hand-mill, the client was quoted for 10 hours of a senior machinist's time.

• The CNC Reality: The machine could churn out that same valve in 45 minutes. Shop owners would literally hide the humming CNC machines out the back, and keep the master machinist hovering out the front for the clients to meet.

• The Play: Shops didn't tell the clients. They continued to bill for the 10 hours.

• The Result: Profit margins jumped from a standard 20% to a staggering 500% on certain parts, just by exploiting the client's ignorance of the new CNC speed increases.

The Knowledge Monopoly

Historian David Noble argued that CNC machines weren't better when they first came out - manual machinists were often faster for one-off parts. However, management pushed CNC primarily because it removed the knowledge monopoly from the workers.

• With CNC, the knowledge moved from the shop floor to the office floor.

• It allowed management to dictate the pace of work without the machinist ever needing to be consulted.

The End Game

The end of the CNC arbitrage window provides a brutal preview of what happens when a secret productivity leap becomes a baseline industry standard. When the knowledge asymmetry vanishes, the pricing floor doesn't just sag, it collapses.

Once CNC machines became affordable and CAD/CAM software became user-friendly, the secret weapon became a commodity. Job shops that once made a killing started undercutting each other just to keep the spindles turning. Prices for standard parts plummeted by 60-80% in a few years. The bespoke premium evaporated because precision was no longer a rare skill - it was a machine setting.

The ultimate price-killer was when the giants - the Boeings and Fords of the world - realized they didn't need the middleman anymore. As the tacit knowledge of the shop floor was codified into G-Code, the 'craft' became a 'file' ... and files are infinitely portable. Clients realized they could hire a CNC programmer/operator to run the same machines in-house for a fraction of the agency's markup.

External shops were forced to drop their prices to Cost + 10% just to prevent their clients from in-sourcing the work entirely. The only shops that kept their high margins were the ones that made a pivot.

• The Pivot: If you were just "making parts", you were a commodity. If you were providing "Aerospace-Grade Quality Assurance and Material Traceability" you could still charge a premium. You stopped selling the shaping of metal and started selling the certainty of the result.
  
  
• Master Machinists became Manufacturing Engineers. They traded their manual "feel" for process optimization. A shop might have 5 CNC machines, but they still needed someone who understood the physics of metallurgy to ensure those machines didn't destroy $50,000 worth of carbide tools in a single afternoon.
  
  
• The AI Parallel: In 2027, writing code will be a commodity. The thing clients will pay for in the future is functional and architectural assurance... did you build the right thing, and build the thing right?

The Generalist Dev Pivot: Breadth Over Depth

Software developers focus will need to shift upwards, onto software architecture, business analysis and the AI tools themselves - using AI tools to drive more productivity for business.

With this shift comes the need for a breadth of knowledge rather than a depth of knowledge. Specialist developers who continue to focus narrowly on just one framework / platform will slowly lose their knowledge monopoly to a machine that never sleeps, doesn't take coffee breaks and doesn't charge for overtime. 

References and further reading
True Stuff: Monk vs. the Printing Press
Gunsmithing Career History

The Manual Machinist Facebook Group
Making the Plunge into CNC
Forces of production: A social history of industrial automation (By David Noble)

Should I be a specialist or a generalist?
Alternative to becoming a Full Stack Developer ... Become a Generalist

Reality check on "AI will replace software engineers in 12 months" claims
The AI Arbitrage Opportunity: Code Just Got Cheap
The Honest Math of Coding with AI Agents in Production

Follow @dodgy_coder on X

Quick Fix Archaeology - 3 famous hacks that changed the world

We’ve all been there... it’s 2pm on a Friday and you’ve just found a bug that defies logic. You don't have time for a robust architectural solution. You have time for a few lines of code that will do the job.

You then tell yourself the biggest lie in software development: I’ll refactor this later. In reality, that temporary hack often ends up becoming the foundation of the entire system. 

If you feel guilty about the random spaghetti code currently holding your production environment together, take heart. Some of the most iconic features in tech history weren't the result of visionary genius or months of planning. They were accidents, hardware limitations, and temporary placeholders that refused to die.

From a core function of the Windows O/S, to the games that defined a generation, the software industry is built on a pile of good enough Friday afternoon hacks that accidentally changed the world.

Here's three famous examples of random hacks that became permanent legends.

1. The Windows Format Dialog's 30 Year Legacy

If you’ve used Windows at any point in the last thirty years, you’ve seen it: the utilitarian, grey format drive dialog box. It’s got a few dropdowns, a quick format checkbox, and a rigid refusal to format any drive larger than 32GB as FAT32.

You might assume a committee of Microsoft architects spent months weighing the trade-offs of cluster sizes and file system overhead to arrive at that 32GB limit.

How it went down: It was one guy, a rainy Thursday morning, and a massive case of this'll do for now.

In 1994, developer Dave Plummer was busy porting the user interface from Windows NT to Windows 95. He reached the Format tool and realized the existing UI wasn't going to cut it. So, he pulled out a piece of paper, noted down the features he thought a user might need (filesystem, cluster size, label), and whipped up a basic vertical stack of options.

He didn't like the look of it. It was meant to be a rough draft, a placeholder that someone else would prettify. To top it off, he had to decide on a maximum volume limit for the FAT32 format. He arbitrarily picked 32GB as the cap, thinking that would be plenty for the hardware of the mid-90s and that someone would eventually write a better tool to replace his placeholder.

The result: Microsoft never replaced it. Dave's Format dialog survived through Windows 98, XP, Vista, 7, 10, and its still there in Windows 11.

Because of that one quick fix, a generation of IT professionals grew up thinking 32GB was a fundamental limitation of the FAT32 architecture. In reality, it was just the limit of Dave's patience that morning. It is perhaps the longest term temporary UI in the history of computing.

2. Space Invaders: The Difficulty Curve Born from Lag

In modern game design, we talk about pacing and difficulty curves like they are sacred sciences. Designers spend hundreds of hours tweaking variables to ensure a game gets progressively harder as the player gets better.

But in 1978, Tomohiro Nishikado, the creator of the classic video game Space Invaders, didn’t have a difficulty setting variable. He had a much bigger problem: the CPU of the 8-bit Intel 8080 was struggling to keep up.

How it went down: The custom game hardware Nishikado built was, by today’s standards, incredibly underpowered. When the game started, the screen displayed 55 alien invaders and the processor was completely maxxed out. It could barely handle rendering all the sprites let alone moving them across the screen. As a result, the aliens moved in a sluggish, rhythmic crawl, left to right, down, right to left, etc.

But as the player started blasting the invaders, something unintended happened. With every alien removed from the screen, the CPU had one less thing to render. The lighter the load, the faster the processor could loop through the code.

The fewer enemies there were, the faster the remaining ones moved.

The result: Instead of trying to fix the timing (which would have been an engineering nightmare on that hardware), Nishikado realized the bug made the game incredibly tense. The frantic thump-thump-thump of the final few invaders zipping across the screen felt like a deliberate design choice to pressure the player.

He left it in.

In doing so, he accidentally invented the Difficulty Curve. It wasn't a line of code that made the game harder; it was the hardware finally being able to breathe. Next time your app slows down under heavy load, don't call it a performance bottleneck... call it Emergent Gameplay.

3. Street Fighter II: The Bug That Built eSports

If you’ve ever played a fighting game and pulled off a three-hit combo, you owe a debt of gratitude to a piece of code that was technically failing at its job.

In the early 90s, the concept of canceling one animation into another didn't exist. Fighting games were polite; you punched, the animation finished, and then you were allowed to punch again. But during the development of Capcom's Street Fighter II, lead designer Noritaka Funamizu noticed something strange while testing.

How it went down: Funamizu was checking the timing of the special moves (e.g. the Hadouken). To make these complex inputs easier for players to pull off, the developers had added a key input buffer... a small window of time where the game would accept a new input - even if the previous animation hadn't quite finished yet.

He discovered that if he timed hitting buttons perfectly, he could land a normal punch and then cancel the rest of that animation by triggering a special move. This allowed him to hit the opponent twice before they even had a chance to recover.

The result: Funamizu thought the timing was so incredibly difficult to get right that no one would ever be able to reproduce it reliably. He figured it was a hidden quirk that wasn't worth the effort to fix or re-code.

He was wrong.

Players discovered it almost immediately. What Funamizu dismissed as a timing bug became the Combo System. It transformed fighting games from slow, back-and-forth matches into high-speed, technical displays of skill. Today, canceling is a core mechanic in almost every fighting game on the market, all because a Capcom designer found a quirky bug and let it stay in.

In Defense of the Hack

So, what’s the lesson here - should we all start writing half baked quick fixes and hope for a miracle? Not exactly.

But there is a profound truth in these stories: Perfect is the enemy of shipped. The Windows format tool wasn't a masterpiece of UI design, but it solved a problem on a rainy Thursday. Space Invaders lagged because the code didn't take into account the hardware, but it created the sort of tense atmosphere that a clean engine never could. These devs weren't aiming for historical legacy; they were just trying to get the job done with the tools and time at hand.

The next time you’re coding a workaround, don't just see it as a hack. You might be looking at a future industry standard. Or at the least, the duct tape that keeps your company going for another 12 months. So, go forth and ship it - you can always refactor it... later.

Further Reading & Sources

- Dave Plummer’s YouTube Channel: The original Windows developer himself tells the story of the Format Dialog and the 32GB limit.

- A detailed look at how Tomohiro Nishikado invented the difficulty curve by accident, and the hardware limitations he faced.

- The Making of Street Fighter II: How the accidental combo system came about, and why Noritaka Funamizu decided to keep it.

Follow @dodgy_coder on X

Alternative to becoming a Full Stack Developer ... Become a Generalist

Starting out
When you're starting out your career as a software developer, you'll typically get a first role as either a backend or frontend dev, and after a couple of years, gain some experience on the other side to become a full stack developer.

Company specific lock in
Since every organisation has its own tech stack, a full stack developer in Company A will have a different set of skills than one in Company B. Those additional skills you learn are still useful to boost your knowledge - it can include: specific cloud services, CI/CD, containerization, DevOps processes, a domain specific library or framework, and the company's SDLC process. 

At this point many developers stay committed to their company's tech stack and remain working as a full stack developer for several more years. My advice - don't just coast as a full stack developer,  branch out!

Branching out
Don't limit yourself to web apps.. branch out as soon as you get the chance, by getting some experience with any of these (if possible as part of your day job)...

• Native mobile app development (Swift or Kotlin)
• Cross platform mobile app development (Flutter or React Native)
• Desktop app development
• A newer backend programming language (Golang, Rust or Elixir)
• AI & ML
• UI/UX design using a tool like Figma

Some other ideas (which might need to be in your own time)...

• IoT (Arduino or Raspberry Pi)
• Game development (Unity or Unreal)
• Blockchain development 

Become a generalist
Your aim is to become a generalist - someone who has deep knowledge in two or more areas and maintains a broad knowledge across many platforms, languages and frameworks.

After becoming a generalist, you'll be able to switch up your job roles, stretching your capabilities a bit each time you move. You'll find that you can apply for a larger variety of roles, increasing the possibility to land your dream job. 

Adapt to new roles
Your varied knowledge will make it easier to apply your skills in new and unfamiliar areas, building up after some years to become a senior developer. Once there, its possible to remain at the senior level for an extended period - as long as you still enjoy it and are still learning, why not.

Career progression
Eventually you might try for a tech team lead or software architect role. Software architects often started out as generalist developers who gained enough varied experience to be able to apply their software design skills into any domain. Tech leads can have a similar background, but they maintain more of a hands on development focus as part of their role, getting involved especially with creating proof of concepts. 

More reading
Generalist vs Specialist - the difference
Bill Gates on the book "Range: Why Generalists Triumph in a Specialized World", by David Epstein 
"The Polymath: Unlocking the Power of Human Versatility", by Waqas Ahmed
"Polymath: Master Multiple Disciplines", by Peter Hollins
What It Means to Be a Software Architect — and Why It Matters
Following the Software Architecture Career Path

Follow @dodgy_coder on X

Thanks to reddit user -NewYork- for this meme

Does Xamarin owe its existence to Unity & Apple?

Yes, Xamarin owes its existence to two other bits of technology that were huge around 2008 - the Unity Game Engine and the iPhone. The reason is that a confluence of events around 2008 provided the push to get the Mono project into mobile app development. This resulted in MonoTouch (for iOS) and Mono for Android, which eventually became Xamarin as we know it today.

The Mono project was founded in 2001 as a free open source implementation of Microsoft's .NET framework on Linux. But Mono had struggled since its inception to find its reason for being. According to Mono's founder, Miguel De Icaza, the hardcore free open source community never fully got behind Mono. The FOSS community feared that Microsoft would eventually cause problems for Mono, due to Microsoft being the creator of .NET. 

Outside of the Linux world however were other more pragmatic people from the MacOSX world who had no problem with Mono. One of these people was Joachim Ante, from Unity. Around 2005 the Unity game engine was just starting out and had a performance problem - their original scripting language of Python was far too slow - they needed something that was an order of magnitude faster. So Unity decided to replace the Python scripting with Mono/C# and immediately got all the performance they needed. This was the early days when the Unity Game Engine ran on MacOSX only. Mono filled the need of being a free open source JIT compiler with the modern language of C#.

Fast forward to 2008 when the iPhone App Store launched; Unity quickly set their sights on being able to compile games for the iPhone. Unity wanted to use Mono, but the additional requirement was that it had to be statically compiled for iOS, because Apple had banned the use of JIT (Just In Time) compilers in iOS Apps.

Unity comes back to us and says “Hey, we have this product on iOS, we need .NET to be statically compiled. Can you do that?” We were like, “Oh, that’s kind of impossible. Well, let’s think about it.”

One of our guys, Zoltán Varga - they went and made a static compiler for .NET, and it was amazing. We gave it to Unity. At this point, Unity is probably four or five employees.
    
They were working at somebody’s garage. And they shipped their product for iOS, built games for iOS using this thing, this 3D tech. They were the kings of this space.
    
- Miguel De Icaza (Xamarin)

Within a year of the iPhone App Store launch, Unity went from 4-5 employees to 80 employees. The iPhone and the App Store had launched Unity's massive growth, and along with this the Mono project had finally found its reason for being - mobile apps. The Mono developers realised there was interest in using .NET for mobile apps - so using the same tech given to Unity, they built their own product - MonoTouch, which allowed developers build native iOS apps using C#. Soon afterward, Mono turned its attention to Android and created Mono for Android.

Mobile app development was new and there were many developers who wanted to get into mobile apps but didn't really want to have to learn Objective-C and Java. So Mono now had a C# based cross platform app development platform with truly native performance. This was the killer combination that ensured Mono would take off in popularity.

The developers behind Mono founded the Xamarin company in 2011, MonoTouch became Xamarin.iOS and Mono for Android became Xamarin.Android. Xamarin was acquired by Microsoft in February 2016 and became a subsidiary of Microsoft, fully focused on the development of Xamarin's open source projects.

Inspiration for this article:

The History of GNOME, Mono, and Xamarin
https://changelog.com/podcast/275

Follow @dodgy_coder on Twitter

Programming an Ethereum Smart Contract with Vyper

and deploying it with MetaMask and MyEtherWallet (MEW)


Introduction

Ethereum has a vast amount of developer resources available, such that for a beginner its hard to know where to start.

If you go with the recommended approach you'd probably choose Solidity along with either JavaScript or golang. JavaScript and golang are traditionally the most well supported languages for the developer tooling around Ethereum. The original Ethereum node software, geth, is written in golang. There's a version of the Solidity smart contract compiler, solcjs, written in JavaScript, and available as a Node.js NPM package.

The other Smart Contract language that is supported by the Ethereum Foundation is Vyper. Vyper is a python-like language that was designed for security, simplicity and testability. In my view this makes Vyper ideal for a beginner. Vyper foregoes some of the power of Solidity (for example, class inheritance and function modifiers) in order to uphold the Vyper principles of being simple and secure.

In this article I'll be stepping you through creating a smart contract with the Vyper programming language, deploying it to the Ethereum test network, and then interacting with the contract - calling its two externally accessible functions. The contract deployment and contract interaction are achieved using two in-browser tools - MyEtherWallet (MEW) and MetaMask.


Background reading

Before you start I would highly recommend this article to get up to speed with the Ethereum ecosystem as a whole.
https://medium.com/@mattcondon/getting-up-to-speed-on-ethereum-63ed28821bbe
Its from 2017 but the content is still valid today.

Along with the Ethereum whitepaper, which is a must-read if you're a developer:
https://github.com/ethereum/wiki/wiki/White-Paper


Installing the Vyper compiler

There's a number of options available to you as documented here:
https://vyper.readthedocs.io/en/latest/installing-vyper.html

One of the simplest options is to install it using python's package manager (pip). I'll start by ensuring you have the python development environment setup correctly.


Installing a recent version of Python and Pip with Pyenv

If you don't have already have a recent version of Python installed, or don't even know, I would highly recommend that you start by installing pyenv. Pyenv is a tool for python version management.

I followed the Pyenv installation instructions for a MacOS installation via homebrew, but there are instructions for other OSes given.

After installing pyenv, you can install the latest version of python with

% pyenv install 3.8.0

You will now have an up to date version of both python and pip available from your terminal command prompt.

Check what version of python is installed:
% python -V

Output:
Python 3.8.0

Check what version of pip is installed:
% pip -V

Output:
pip 19.2.3 from /Users/hg/.pyenv/versions/3.8.0/lib/python3.8/site-packages/pip (python 3.8)


Installing the Vyper compiler

Once you have python and pip installed aready, you can install the Vyper compiler with:

% pip install vyper

Check what version of Vyper is installed:

% vyper --version

Output:
0.1.0b16+commit.5e4a94a


Writing a smart contract in Vyper

For the first contract, we're going to keep things very simple and go with a public storage contract.
All the contract does is stores a single number in its storage area, and implements two public accessor functions - a getter and a setter.

Use a text editor and open a new file named storage.vy

Note that vy is the file extension for Vyper source code.

Here's the Vyper code:

stored_data: uint256

@public
def set(new_value : uint256):
    self.stored_data = new_value

@public
@constant
def get() -> uint256:
    return self.stored_data

Line 1 declares a variable named 'stored_data' of type 'uint256'. This is the only thing that the contract will store on the blockchain.

Line 3 (def set...) declares the public set function, to update the 'stored_data' variable.

Line 9 (def get...) declares the public get function, to get the 'stored_data' variable.

Its important to note that these two functions get and set are marked public and so can be 'called' by anyone - by using Ethereum client software like MyEtherWallet, or programmatically via the web3 or by other library.

Calling a public function on a smart contract actually consists of sending a transaction to the deployed contract's address - but this is an implementation detail hidden that is hidden by client software or libraries.

Further reading about the structure of contracts in Vyper:
https://vyper.readthedocs.io/en/latest/structure-of-a-contract.html


Compiling the Vyper smart contract

To compile the contract into EVM bytecode:

% vyper -f bytecode storage.vy > storage.bin

To generate the ABI for the contract:

% vyper -f abi storage.vy > storage.abi

The ABI is a JSON format interface specification file, and it is needed to be able to interact with the smart contract (i.e. call its functions).


Deploy the smart contract to the Rinkeby test network

Install MetaMask

If you haven't already, now is a good time to install the MetaMask plugin/extension into your browser - https://metamask.io/
Setup MetaMask with a seed phrase and it will create an in-browser Ethereum wallet that you can use for real transactions, or in this case, test transactions.

When MetaMask is setup, at the top right you should see the network dropdown.

Change this to 'Rinkeby Test Network'. Press the DEPOSIT button, then press the GET ETHER button under the TEST FAUCET option.

After opening https://www.rinkeby.io/#stats use the 'Crypto Faucet' button on the left and follow the instructions. The minimum option (3 ETH) will be more than enough for test purposes and to deploy this contract.

The second thing you'll need to do is to setup MyEtherWallet (MEW). This will let you deploy and interact with your smart contract.


Setup MyEtherWallet (MEW)

Go to https://www.myetherwallet.com and setup the seed phrase.

Now you'll need to give MyEtherWallet (MEW) access to your MetaMask wallet, which contains the 3 ETH for testing.

Go to https://www.myetherwallet.com/access-my-wallet and press the browser extension option.

It should come up with a 'Access via MetaMask' window, and you'll need to grant it permission. Press the 'Access My Wallet' button.


Deploy the smart contract

Inside MyEtherWallet (MEW), press the left hand side option 'Contract' then 'Deploy Contract'.

From the terminal, issue this command:

% cat storage.bin

Output:
0x6100f456600436101561000d576100ea565b600035601c52740100000000000000000000000000000000000000006020526f7fffffffffffffffffffffffffffffff6040527fffffffffffffffffffffffffffffffff8000000000000000000000000000000060605274012a05f1fffffffffffffffffffffffffdabf41c006080527ffffffffffffffffffffffffed5fa0e000000000000000000000000000000000060a0526360fe47b160005114156100c25734156100ba57600080fd5b600435600055005b636d4ce63c60005114156100e95734156100db57600080fd5b60005460005260206000f350005b5b60006000fd5b6100046100f4036100046000396100046100f4036000f3

Using the mouse, copy the contents of the file from the terminal prompt.

Inside MEW, paste the copied text contents into the bytecode field.

On the terminal again, issue this command:

% cat storage.abi

Output:
[{"name": "set", "outputs": [], "inputs": [{"type": "uint256", "name": "new_value"}], "constant": false, "payable": false, "type": "function", "gas": 35315}, {"name": "get", "outputs": [{"type": "uint256", "name": "out"}], "inputs": [], "constant": true, "payable": false, "type": "function", "gas": 1181}]

Using the mouse, copy the contents of the file from the terminal prompt.

Inside MEW, paste the copied text contents into the ABI/JSON field.

Enter a name for your contract, e.g. 'storage1'.

Press the 'Sign Transaction' button.

MetaMask will open up a window where you'll be able to confirm the deployment of your contract.

You'll see the gas fee and total.
You can press on the data tab and you'll see the bytecode that you pasted earlier.

Press the Confirm button to proceed with the deployment of your contract.

You may need to wait several seconds for the transaction to be confirmed at this point.
MetaMask should give you a successful deployment popup and link you to the transaction on etherscan.io.
E.g.
https://rinkeby.etherscan.io/tx/0x36663b338ab0eaa7d7cdd91aa5abacdc273757ff56b81221d76a2ff0aedc9860

Here you can see the address of your newly deployed contract. In my case it is here:
https://rinkeby.etherscan.io/address/0x7baad2f634d6bde84916e7d6db40ca2e502eaff6


Side note on contract addresses

Contract addresses are calculated deterministically, based on the account that created it. They are based on the nonce value of your account. So it is possible to know in advance what the contract address will be, if necessary.

Details here: https://ethereum.stackexchange.com/questions/760/how-is-the-address-of-an-ethereum-contract-computed


Interacting with the smart contract

Now that your contract is deployed, its time to interact with it - call its get and set functions.

The get function can be called 'for free' - it doesn't cost any gas, because its just returning the current state of the blockchain.
Calling the 'set' fuction however must be paid for in gas, because by calling it you are actually changing the current state of the blockchain.

Go back to MEW and navigate to the left hand side 'Contract' option then 'Interact with Contract'.

Paste your newly created contract address into the 'Contract Address' field.

In the ABI/JSON field, past your ABI file contents.

Press the Continue button.

There's a dropdown which shows 'Select an item'. This lists all of the public functions on the smart contract. There's only two available - get and set.

Choose get first, it will execute immediately and show the result being 0. 0 is the default value for uninitialised storage in Ethereum.

Now choose 'set' from the dropdown.

Enter the required value into the new_value field, e.g. 88.

Leave the Value in ETH as 0.

Press the 'Write' button.

MetaMask will open up a window where you'll be able to confirm your contract interaction.
What you're actually doing here is sending a transaction to the contract with a value in the data field - the data specifies to the EVM which function is being called (set) and the value of the parameter to it (88).

Press the confirm button.

You may need to wait several seconds for the transaction to be confirmed.

MetaMask should give you a confirmed transaction popup and link you to the transaction on etherscan.io.
E.g.
https://rinkeby.etherscan.io/tx/0x42af3501fff6ddd67a97cc52c94565f149f4d7f985d223523cebae2efc693bbb

Press the "Press to see more" link at the bottom of this page on etherscan.io to see the detail of the function call you made.

Go back to MEW and this time select the 'get' from the dropdown.

Confirm that the value you set is now reflected by the get.

You have now successfully deployed an Ethereum smart contract written in Vyper, and interacted with it using MetaMask and MyEtherWallet (MEW).

Congratulations!


Final notes - can you modify a smart contract?

Note that once a smart contract is deployed, you can't modify it; it is immutable and exists on the Ethereum blockchain forever.

If you need to modify or update the contract, you'll need to deploy the updated code to a new contract address.

There are various techniques for handling contract "upgrades" including migrating the existing storage. There's a good article here on this topic: https://mixbytes.io/blog/storage-upgradable-ethereum-smart-contracts

Note also that a contract can destroy itself (along with its storage), via the selfdestruct() function, as documented here: https://vyper.readthedocs.io/en/v0.1.0-beta.15/built-in-functions.html#selfdestruct

Once destroyed, the contract and its storage are removed from that block onwards. After destruction, it is technically still possible to see the historical contract bytecode and storage, which exists on earlier blocks of the Ethereum blockchain.


Follow @dodgy_coder on Twitter

Programming Bitcoin Cash (BCH) with the NBitcoin .NET library and C#

The NBitcoin library is the most active and well supported library in .NET for working with Bitcoin and other similar cryptocurrencies.

NBitcoin fully supports Bitcoin Cash (BCH), however the ebook and programming guide examples focus solely on Bitcoin Core (BTC).

The problem you encounter when following the NBitcoin guide is firstly that the QBitNinja API only supports Bitcoin Core and secondly that broadcasting the transaction seems to require either running a full local node or using the QBitNinja API.

In this tutorial I'll show you how to spend your Bitcoin Cash using the NBitcoin library running under dotnet core, without the need for running a full local node or for accessing the QBitNinja API.

The program you write here will create a new transaction, sign it with your private key, and broadcast it to the Bitcoin Cash network.

Dotnet core is the preferred programming environment for NBitcoin. Dotnet core is open source and runs under the Linux, MacOSX and Windows operating systems.

Bitcoin Cash is the ideal cryptocurrency for experimenting with programming APIs and libraries - you can send small transactions for very low fees, typically for a fraction of one US cent.


Step 1: Project Setup

Follow the setup guide as normal:
https://programmingblockchain.gitbook.io/programmingblockchain/introduction/project_setup

The rest of these steps 2-12 below loosely follow the "Spend Your Coin" guide:
https://programmingblockchain.gitbook.io/programmingblockchain/bitcoin_transfer/spend_your_coin

Its not absolutely required, but for a more complete and in depth understanding, I would recommend you read through the "Spend Your Coin" guide above (with the knowledge that it applies to Bitcoin Core) before proceeding with the rest of the below steps.


Step 2: Add support for Bitcoin Cash

On the command line:

dotnet add package NBitcoin.Altcoins

The code - add these using statements to the top of the C# source file.

using NBitcoin;
using NBitcoin.Altcoins;
using NBitcoin.Protocol;

And at the beginning of the program, add this:

// Important Note - this is not test code.
// It is going to run in production (called the "mainnet").
var network = NBitcoin.Altcoins.BCash.Instance.Mainnet;


Step 3: (Optional) Generate a new private key and address

The below code snippet generates a new BCH private key and BCH address using the NBitcoin library.
  
// Generate a random private key.
Key rawPrivateKey = new Key();

// The private key, also known as the Bitcoin secret or the WIF (Wallet Interchange Format).
// If you intend to use it, make sure you save the below somewhere safe!
BitcoinSecret privateKey = rawPrivateKey.GetBitcoinSecret(network);
Console.WriteLine("privateKey = " + privateKey);
Console.WriteLine("address (from privateKey) = " + privateKey.GetAddress(ScriptPubKeyType.Legacy));

Alternatively you can generate a new private key and address using BCH wallet software.


Step 4: Setup the variables for your private keys and addresses

To spend your Bitcoin Cash, you'll need to know the private keys of both the "destination" BCH address and the "from" BCH address.
The "from" BCH address is also known as the input address or the outpoint to spend.

Here's the code to setup the address and private keys of both the "destination" address and the "from" address.

// Destination - private key and address. The destination of the new transaction we are creating.
// Note: its not strictly necessary for creating the transaction to have the private key of the destination,
// but its better to add it here so that you know that you have access to it, and that the money won't be 'lost'.
var privateKey = new BitcoinSecret("PASTE_YOUR_DESTINATION_ADDRESS_PRIVATE_KEY_HERE", network);
Console.WriteLine("dest privateKey = " + privateKey);
var address = privateKey.GetAddress(ScriptPubKeyType.Legacy);
Console.WriteLine("dest address = " + address);
Console.WriteLine("dest address scriptPubKey= " + address.ScriptPubKey);

// Input Transaction - private key and address. The from address.
var inPrivateKey = new BitcoinSecret("PASTE_YOUR_FROM_ADDRESS_PRIVATE_KEY_HERE", network);
var inAddress = inPrivateKey.GetAddress(ScriptPubKeyType.Legacy);
Console.WriteLine("inPrivateKey = " + inPrivateKey);
Console.WriteLine("inAddress = " + inAddress);
Console.WriteLine("inAddress scriptPubKey= " + inAddress.ScriptPubKey);

You can run the program now to make sure its working - on the command line:

dotnet run


Step 5: Determine the Transaction ID of the "from" address

Now you need to determine the transaction ID and index number of your "from" address by looking at the transaction in a blockchain explorer and plugging in the correct TxId and index number below.

// Determine the previous output that will be spent, as the Input to our new transaction.
// For example:
// https://explorer.bitcoin.com/bch/tx/292f70e71f8bc2e94b7c0ac46c4e89371dc59b821639de67376f6f0b09544d92
string txInIdString = "292f70e71f8bc2e94b7c0ac46c4e89371dc59b821639de67376f6f0b09544d92";
uint txOutIndex = 0; // <== Ensure this index is correct!
OutPoint outPointToSpend = OutPoint.Parse(txInIdString + ":" + txOutIndex);


Step 6: Create the new transaction

var transaction = Transaction.Create(network);
transaction.Inputs.Add(new TxIn()
{
    PrevOut = outPointToSpend
});


Step 7: Setup the amount to spend and the miner fee

// Suggested miner fee for this transaction, as of February 2020,
// is 0.000003 BCH or around USD 0.001 (a tenth of a cent).
// Check recent blocks for guidance.
var minerFee = new Money(0.000003m, MoneyUnit.BTC);  

// Replace below with your amount.
// It is the total unspent amount of the "from" address.
var txInAmount = new Money(0.0021m, MoneyUnit.BTC);

// Move to the destination address.
var spendAmount = txInAmount - minerFee;
transaction.Outputs.Add(spendAmount, address.ScriptPubKey);


Step 8: Add a message to the transaction, using the OP_RETURN template (max 80 characters)

var message = "Test 1: using the NBitcoin library to move Bitcoin Cash. BCH Rocks!";
var bytes = Encoding.UTF8.GetBytes(message);
transaction.Outputs.Add(Money.Zero, TxNullDataTemplate.Instance.GenerateScriptPubKey(bytes));


Step 9: Sign the transaction

// Get the ScriptPubKey from the private key of the outPointToSpend.
transaction.Inputs[0].ScriptSig = inAddress.ScriptPubKey;

// Sign the transaction with the input private key.
var txInId = uint256.Parse(txInIdString);
var inCoin = new Coin(txInId, txOutIndex, txInAmount, inAddress.ScriptPubKey);
transaction.Sign(inPrivateKey, inCoin);


Step 10: Determine the TxId of your transaction, which is just its hash

Console.WriteLine("New TxId: " + transaction.GetHash());

Now is a good time to run the code and check its all working. From the command line:

dotnet run


Step 11: Broadcast your transaction to the Bitcoin Cash network

This is the final step and should only be attempted if your program runs fine up to step 10.

Before you run it, confirm your amount to spend is correct.

//
// Connect to a BCH node and broadcast the transaction.
// See here for the DNS Seed list:
// https://github.com/Bitcoin-ABC/bitcoin-abc/blob/master/src/chainparams.cpp
//
using (var node = Node.Connect(network, "seed.bchd.cash:8333"))
{
    // Say hello to the node.
    node.VersionHandshake();

    // Advertise your transaction (send just the hash).
    node.SendMessage(new InvPayload(InventoryType.MSG_TX, transaction.GetHash()));

    // Send the contents of the transaction.
    node.SendMessage(new TxPayload(transaction));

    // Wait for the message to be sent.
    Thread.Sleep(5000);
}

Run your program the command line:

dotnet run


Step 12: That's it, well done for making it to the end!!

If everything went well, your new transaction was accepted by the Bitcoin Cash network, and it will show up in a block explorer such as this one:

https://explorer.bitcoin.com/bch/tx/3ecf0f0dafd26e8d788b59a433bf00e1c3c079e82dada5111e899c87a75dadff

Replace the above TxId with yours from step 10.

Your new transaction will be listed initially as having 0 confirmations, which means its in the mempool.

Now you just need to wait for your transaction to be confirmed. This will happen as soon as the next block is mined and your transaction gets added to that block by the winning miner.

Follow @dodgy_coder on Twitter

The Default Files Folder Pattern

Software installation best practices

When you've got critical settings files that absolutely should never be overwritten or cleared back to defaults, this pattern has always worked well for me. It can apply to both Windows, Linux and Mac based software.

The installation method can either be a simple file copy utility/archive or something more complex like a Windows installer.

An example target structure might look something like this:

/MyApplication
    /bin           => Application binaries.
    /defaults      => A default version of all settings files.
    /docs          => Documents or manuals.
    /settings      => Critical settings files.
             
The settings folder contains the critical settings files and is not part of the installer. The installer includes only the bin, defaults and docs folders. So installing the software only overwrites bin, defaults and docs, but never the settings. This applies equally to Windows installer packages - for this case, just don't include the settings folder in the Windows installer package. The defaults folder contains the default version of all of the the files expected in the settings folder.

Whenever the software accesses a particular file in settings the following lazy initialisation logic is used ...

- Does the settings folder exist?
    - Yes: Continue
    - No:  Create the folder and continue
   
- Does the file exist?
    - Yes: Open it
    - No:  Copy the file from the defaults folder into the
           settings folder, then open it

By following the above logic, you ensure that an existing critical settings file is never overwritten.

From reading the latest report on the deadly Airbus A400M crash, its claimed that the cause was that their software installation procedure did the equivalent of overwriting a settings file or clearing it back to defaults. In this case, the settings file contained calibration parameters that were critical to the operation of 3 out of the 4 propeller engines.

Follow @dodgy_coder

Subscribe to posts via RSS

How to learn a new programming language

Here's some tips on learning a new programming language. They aren't listed in any specific order. Hopefully you'll gain from this at least one new tip that will help you to become proficient in the next language you learn.

1. Build something you actually need right now. This could be either a tool you can use in your day job, or something useful you can make use of at home.
   
   Consider these example projects ...
   
   • Write a simple unit testing framework. Many new languages don't have any unit testing frameworks available when they are first introduced. This project will force you to use areas of the language like reflection and meta-programming. Once completed, it becomes useful straight away, for unit testing your future work in the language.
   • Implement a disk usage tool; it summarizes the disk usage of all directories on a disk and outputs to the console. It doesn't require overly complex algorithms but touches a lot of the basics: recursion, filesystems, command line parsing and output formatting.
   • Implement a backup/archive script which has command line switches to exclude certain file extensions. It should place the backup into a single .zip or .tar.gz file. The project will touch on the following: recursion, filesystems, command line parsing, compression libraries and regular expressions.
     
2. Port an existing, well known program to the new language. Since you are porting it, you already have the application design work done. This frees up your mind to focus on the specifics of the new language. After you've finished you'll then have a good reference to which you can refer back to, when comparing the old with the new language.
   
   
3. Find a decent book on the language and read through it all as fast as you can. The goal is not to memorize everything, but to soak up the ideas and idioms of the language. Then write some small but non-trivial project. When you get stuck, hopefully it'll trigger a memory of something from the book, and you can go back to refer to it.
   
   Many of the "in a Nutshell" and "Head First" series of books, both published by O'Reilly, are highly rated by readers - they are available for many popular languages (C, C++, C#, Java, Python, JavaScript, PHP).
   
   
4. Mix action with equal parts learning (reading books/tutorials). Too much action without learning, and you get a lot of poor quality code. Too much learning without enough action, and you fail to absorb the material to a deep enough level.
   
   
5. Study reference works on public repositories. Find a medium sized project on GitHub which is written 100% in the language. Read though the code and try to understand it. Look for projects written by the language designers or an acknowledged expert.
   
   As an example, with Go, the standard libraries for the language are written in Go and are open source, e.g. here is part of the strings package.  In addition, Brad Fitzpatrick and other members of the Go team have several projects on GitHub that you can read and learn from, e.g. here is a Go client for Memcache.
   
   
6. Devote large, uninterrupted chunks of time, at least half a day, to learning the new language. Brief, half hour sessions over the course of the week aren’t really useful, because most of the time would be spent just getting back up to speed on what you previously studied.
   
   
7. Learning a language shouldn’t just be a solitary endeavor. There are plenty of people who have made the same mistakes that you have, so asking for help is a great way to overcome problems when you get stuck. Some possible sources of help online: Language-specific IRC channels, StackOverflow, Twitter, Facebook groups, Quora, Google+, Google groups. You can also submit your finished code to these forums after you've completed a project; people more experienced with the language than you will often be able to identify areas which can be improved or simplified.
   
   
8. Use an editor with syntax highlighting. Perennial favorites such as Vim and Emacs, plus newer editors such as Sublime Text, feature support for most if not all programming languages and are available for all major operating systems. Some languages are often associated with specific IDEs; these are a good idea when learning a new language. These are generally ...
   
   • Eclipse IDE for Java and Android development.
   • Xcode for Objective-C and iOS development (on Mac OSX only).
   • Visual Studio IDE for C#, C++, VB.NET, F# (on Windows only).
   All of the IDEs and editors listed above are either completely free or have an unlimited trial version available.
   
   
9. Working on a real project with real customers and deadlines is a white hot crucible for learning a new programming language. If you really need to learn a language quickly, then consider taking on a new job which requires it. Once you've got the job, you'll have no other choice but to learn it quickly.
    
10. Finally, a tip from The Pragmatic Programmer, Tip #8 "Invest Regularly in Your Knowledge Portfolio":
    

    "Learn at least one new language every year. Different languages solve the same problems in different ways. By learning several different approaches, you can help broaden your thinking and avoid getting stuck in a rut. Additionally, learning many languages is far easier now, thanks to the wealth of freely available software on the Internet." 

    
    
    Follow @dodgy_coder
    
    Subscribe to posts via RSS

Big Ball of Mud Design Pattern

In "Big Ball of Mud", Brian Foote and Joseph Yoder propose that the default (and most common) software architecture in use is the "Big Ball of Mud" pattern and go on to discuss six additional patterns and activities that it gives rise to: "Throwaway Code", "Piecemeal Growth", "Keep it Working", "Shearing Layers", "Sweep it Under the Rug" and "Reconstruction".

Their original article is located here and can be downloaded in PDF form here: Big Ball of Mud by Brian Foote and Joseph Yoder [PDF download]

I have picked out what I think are the highlights of their article ...


Big Ball of Mud ... alias Shantytown or Spaghetti Code

Shantytowns are usually built from common, cheap materials with simple tools and using unskilled labor. The construction and maintenance of the shantytown is labor intensive, and there is little or no labor specialization - each builder must be a jack of all trades. There's no overall planning, or regulation of future growth.

Too many of our software systems are, architecturally, little more than shantytowns. Investment in tools and infrastructure is often inadequate and the tools that are used are primitive. Parts of the system grow unchecked, and the lack of architecture and planning allows problems in one part of the system to erode and pollute adjacent portions. Deadlines loom like monsoons, and architectural elegance seems unattainable.

The time and money to chase perfection are seldom available and there is a survival at all costs attitude, to do what it takes to get the software working and out the door on time. The biggest cost borne by the Big Ball of Mud development is the lack of a decent architecture.


Common features of Big Ball of Mud Code

• Data structures are haphazardly constructed, or non-existent.
• Everything talks to everything else.
• Important state data is global.
• State data is passed around though Byzantine back channels that circumvent the system's original structure.
• Variable and function names are uninformative and misleading.
• Functions use global variables extensively, as well as long lists of poorly defined parameters.
• Functions themselves are lengthy and convoluted, and perform several unrelated tasks.
• Code duplication.
• The flow of control is hard to understand, and difficult to follow.
• The programmer’s intent is next to impossible to discern.
• The code is simply unreadable, and borders on indecipherable.
• The code exhibits the unmistakable signs of patch after patch at the hands of multiple maintainers, each of whom barely understood the consequences of what he or she was doing.
• Did we mention documentation? What documentation?

Working with Big Ball of Mud Code

Some software engineers come to regard life with the Big Ball of Mud as normal and become skilled at learning to navigate these quagmires, and guiding others through them. Over time, this symbiosis between architecture and skills can change the character of the organization itself, as swamp guides become more valuable than architects.

As per Conway's Law, architects depart in futility, while engineers who have mastered the muddy details of the system they have built, prevail. The code becomes a personal fiefdom, since the author care barely understand it anymore, and no one else can come close. Once simple repairs become all day affairs, as the code turns to mud.


Throwaway Code ... alias Quick Hack or Protoduction

While prototyping a system, you're normally unconcerned with how elegant or efficient your code is. You plan that you will only use it to prove a concept and once the prototype is done, the code will be thrown away and written properly. As the time nears to demonstrate the prototype, the temptation to load it with impressive but utterly inefficient realizations of the system’s expected eventual functionality can be hard to resist. Sometimes, this strategy can be a bit too successful. The client, rather than funding the next phase of the project, may slate the prototype itself for release.

This quick-and-dirty coding is often rationalized as being a stopgap measure. More often than not, the time is never found for this follow up work. The code languishes, while the product flourishes. It becomes a protoduction - a prototype that gets used in production.

Once it becomes evident that the throwaway code is going to be around for a while, you can turn your attention to improving its structure, either through an iterative process of Piecemeal Growth, or via a fresh draft, as discussed in the Reconstruction pattern below.


Piecemeal Growth ... alias Refactoring

Successful software attracts a wider audience, which can, in turn, place a broader range of requirements on it.

When designers are faced with a choice between building something elegant from the ground up, or undermining the architecture of the existing system to quickly address a problem, architecture usually loses.

In the software world, we deploy our most skilled, experienced people early in the lifecycle. Later on, maintenance is often relegated to junior staff, and resources can be scarce. The so-called maintenance phase is the part of the lifecycle in which the price of the fiction of master planning is really paid. It is maintenance programmers who are called upon to bear the burden of coping with the ever widening divergence between fixed designs and a continuously changing world.

Piecemeal growth can be undertaken in an opportunistic fashion, starting with the existing, living, breathing system, and working outward, a step at a time, in such a way as to not undermine the system’s viability. You enhance the program as you use it. Massive system-wide changes are avoided - instead, change is broken down into small, manageable chunks.


Keep It Working ... alias Continuous Integration

Businesses become critically dependent on their software and computing infrastructures. There may be times where taking a system down for a major overhaul can be justified, but usually, doing so is fraught with peril. Therefore, do what it takes to maintain the software and keep it going. Keep it working.

This approach can be used for both minor and major modifications. Large new subsystems might be constructed off to the side, perhaps by separate teams, and integrated with the running system in such a way as to minimize disruption.

A development build of each product can be performed at regular intervals, such as daily or even more often via an automated build tool. Another vital factor in ensuring a system's continued vitality is a commitment to continuous testing, which can be integrated into the automated build process.


Shearing Layers

Software never stands still. It is often called upon to bear the brunt of changing requirements, because, being as that it is made of bits, it can change.

Over time, the software's frameworks, abstract classes, and components come to embody what we've learned about the structure of the domains for which they are built. More enduring insights gravitate towards the primary structural elements of these systems and change rarely. Parts which find themselves in flux are spun out into the data, where users can interact with them. Software evolution becomes like a centrifuge stirred by change. The layers that result, over time, can come to a much truer accommodation with the forces that shaped them than any top-down planning could have devised.


Sweeping It Under The Rug

At first glance, a Big Ball of Mud can inspire terror and despair in the hearts of those who would try to tame it. The first step on the road to architectural integrity can be to identify the disordered parts of the system, and isolate them from the rest of it.

Overgrown, tangled, haphazard spaghetti code is hard to comprehend, repair, or extend, and tends to grow even worse if it is not somehow brought under control. If you can’t easily make a mess go away, at least cordon it off. This restricts the disorder to a fixed area, keeps it out of sight, and can set the stage for additional refactoring.


Reconstruction ... alias Total Rewrite

One reason to start again might be that the previous system was written by people who are long gone. Doing a rewrite provides new personnel with a way to reestablish contact between the architecture and the implementation. Sometimes the only way to understand a system it is to write it yourself. Doing a fresh draft is a way to overcome neglect. Issues are revisited. A fresh draft adds vigor. You draw back to leap. The quagmire vanishes. The swamp is drained.

When a system becomes a Big Ball of Mud, its relative incomprehensibility may hasten its demise, by making it difficult for it to adapt. It can persist, since it resists change, but cannot evolve, for the same reason. Instead, its inscrutability, even when it is to its short-term benefit, sows the seeds of its ultimate demise.


The above are highlights from the original article, which is located here ... Big Ball of Mud by Brian Foote and Joseph Yoder [PDF download]


Some further reading on Programmers.StackExchange ...

I've inherited 200K lines of spaghetti code — what now?
How to convince my boss that quality is a good thing to have in code?
How to keep a big and complex software product maintainable over the years?
Techniques to re-factor garbage and maintain sanity?
When is code “legacy”?
What is negative code?


Some related books ...

Working Effectively With Legacy Code ... by Michael Feathers [Amazon]
Refactoring: Improving the Design of Existing Code ... by M. Fowler, K. Beck, et al. [Amazon]
Design Patterns: Elements of Reusable Object-Oriented Software ... by the Gang of Four [Amazon]
Patterns of Enterprise Application Architecture ... by Martin Fowler [Amazon]
Domain Driven Design: Tackling Complexity in the Heart of Software ... by Eric Evans [Amazon]
Head First Design Patterns by E. Freeman, E. Freeman, et al. [Amazon]

Follow @dodgy_coder

Subscribe to posts via RSS

Defensive copy and paste coding

I've got into the habit of doing this check at the end of any development which has involved some copy & pasting of existing code. It's been useful for me in picking up issues before build/test/commit.

It just involves getting a reference count of all occurrences the new variable (or function) compared with the old variable (or function)...

• Select the newly added variable (or function) name
• Right-click to bring up the context menu
• Select the "Find all references" option

The screenshot shown is from Visual Studio, but this feature is also available in other IDEs and editors, such as Eclipse (via the "References" context menu). Alternatively, if you're not using an IDE, a simple text search across all files in your project will be just as useful, assuming that the search string is unique within your project.

Often, you'd expect the reference count should match with the one you've copy & pasted from (as shown above). If it doesn't match, then by looking at the references which are different, you should be able to easily reason about why, and whether its expected or not. If its unexpected, that could mean there's an error in your code.

So who admits to copy & paste coding - isn't it a sign of bad programming? ... if you can copy & paste big blocks of code, followed by only a few small changes then that's a code smell - you should probably extract the common code into a new function and call it twice. Agreed on that, but there is still many cases where you do have a valid reason to copy existing code. One example is to make fine grained changes to some logic, when it might not be worth the additional complexity of creating a generic function to handle both cases. Or in the case shown above, when I'm copying the declaration of a collection member.

This is a pretty simple and obvious technique, and it might be well known to many already, but I thought I'd mention it anyway. It can also be used outside of the copy & paste case - just mentioning it here because that's the case I've used it more often.

Follow @dodgy_coder

Subscribe to posts via RSS