Extreme programming (XP) is an alternative software development methodology that would be described as an agile methodology. It’s a competitor to scrum, but more focused on the developer experience, less prescriptive of specific organizational practices, and more prescriptive of technical practices. I was familiar with the concepts of XP and recently picked up the second edition of Extreme Programming Explained. This new edition refined some of the technical practices about deployment since tools now exist for even more rapid deployment than what was initially conceived.
The build time practice is interesting, the idea being that a continuous integration build/test cycle should take ten minutes. While you could make the build faster than 10 minutes, keeping it a bit longer generates a decent mental break to allow someone to get a cup of coffee or get up and stretch. Whereas, if it’s slower than that, there is a tendency to move onto a different task and you can lose context on the old task and the new task. It matches with my experience; although I hadn’t been able to articulate the solution, I had seen the problem.
The overall methodology seems solid, however it doesn’t market itself to the whole business the way scrum does which seems to have impacted the adoption of the methodology as a whole. The practices suggested are all pretty straight forward:
- colocate the team,
- construct a team with all necessary skills on the team,
- have visible progress locators,
- work when you can really concentrate on it,
- pair program,
- user stories,
- a weekly cycle,
- a larger quarterly cycle,
- the above build time practice,
- continuous integration,
- test first programming, and
- incremental design.
Most modern software teams would be in favor of most, if not all, of these practices. Some of the practices are outside the control of the team and would need significant management support, but most are things the team can control.
I don’t think that the differences between this and other agile project management methodologies are that significant. The biggest difference with scrum I can see would be that scrum has fixed reflection periods whereas XP has continuous reflection with impromptu kaizen events. I think that this difference between XP and scrum would allow you to differentiate yourself from all of the scrum implementations that are out there but never finished. I don’t think that the book adds much to my understanding of software engineering, however it’s an excellent selection of software engineering practices. If you’re looking for a different perspective on agile methodologies this would be an interesting read.
I ran across badssl.com recently, and needed to share. The basic idea of the site is that it hosts a number of subdomains with all sorts of variants of SSL certificates. The example certificates cover the whole range of things that can go wrong with a certificate, including expiration, self signed certs, revoked certificates, and certificates for the wrong host. It also checks the strength of cryptography being used and has certificates specifying multiple different kinds of encryption to be tested against. This is all so you can see that your browser is securing you properly.
There is a more interesting use case however. When you go over to the associated github repo there are instructions for booting up the site locally inside a docker container so you can test your code against it as part of your automated test suite to test all sorts of other networking code outside of a browser. The container hosting a separate copy of the site avoids putting your integration tests in a path where they reach out to the public internet for resources. Having your integration tests work with public resources on the internet isn’t a good practice for a number of reasons, such as the time it takes to round trip, the dependency on someone else’s infrastructure for your processes, and just being inconsiderate of someone else’s resources. But, this container lets you avoid all of the work associated with defining what certificates are needed, generating the various certificates, and installing all of certificates.
The test case we used the certificates for didn’t turn up any bugs, but it did make us confident in the implementation. This confidence helped us move along more quickly and be sure we were appropriately securing the connections.
Working Effectively With Unit Tests is a discussion not of when to unit test or how to unit test, but how to know when you’ve done it well. It works backwards from the idea that tests should be Descriptive And Meaningful Phrases(DAMP) as opposed to the traditional software pneumonic Don’t Repeat Yourself (DRY). By allowing some duplication in tests and focusing on the clear intention of what is to be accomplished you get tests that are easier to read and tests that are more focused on the object under test rather than the collaborators of the test.
The style being described forces out a lot of the elaborate mock setups common in most first attempts at unit testing. This is a definite good intention, however like most resources, I feel it comes short at describing a means to actually get rid of these sorts of problems in real applications, as opposed to toy applications in books and articles. The ideas it provides do work towards those ends admirably. To me, the ideas presented seem to drive towards a more functional style of programming; methods were getting more arguments which made the methods more flexible, and the objects they lived on were less prone to carrying around extraneous state. The book didn’t discuss this in functional programming terms, but sort of implied that was a goal around the edges.
Compared to some of the other books on unit testing I’ve read, this felt more concise, and it was definitely less focused on a specific framework for doing testing. It feels written for someone who has been doing unit testing for a while and has not been getting value from the activity, or has been having maintainability problems with tests. For those audiences it seems like it is a good perspective towards trying to get out of their problems. For people new to unit testing, it may be a little to broad in what you should do and not prescriptive enough.
As a working programmer, encryption doesn’t seem like it changes much. AES and RSA public key cryptography have been fairly consistent in the world for a while. Key size recommendations have held up to the projections on computing power, so the overall landscape of implementation hasn’t had much movement. There has been a big emphasis on deciding to encrypt web traffic and lots of other things, but no real changes in the underlying technology.
The unveiling of a 72 qubit quantum computer and some of the work I’ve been doing on encryption at my job has had me thinking about the future of encryption. The jump from 17 qubits in 2017 to 72 already this year makes me think we’re getting close to an inflection point where quantum computing goes from a toy to a realistic threat to existing crypto systems.
Lattice-based cryptography is the leading contender for quantum resistant cryptography. The math behind it is based on the same math that describes the be arrangement of atoms in a crystal, but instead of happening in a three dimensional space it happens in an arbitrarily high dimension. I don’t understand the math behind this in three dimensions let alone higher dimensions. However, I do appreciate that the idea of the hard problem to be solved is based on a normal concept, like elliptic curve cryptography factoring integers. Understanding the idea helps me trust that the underlying math makes sense, even if I don’t understand the math itself.
Looking into this I stumbled into a different idea that was much more radical. Homomorphic encryption is the idea that you can do work over two different encrypted values such that the encryption is distributed over other arbitrary operations. So essentially
Encrypted(a) + Encrypted(b) = Encrypted(a+b)
However this works for all operations not just addition. Practically, this is overkill for any normal application; however, if the party with the data and the party with an algorithm are unwilling to trust each other you could use this to send the data to the algorithm securely and process it. While this seems like an amazing technology from a security and privacy perspective, there is a downside – it currently takes ~13 ms per logical gate to process. So, even something simple like adding two integers would take seconds to complete. You won’t be able to encrypt your data and give it to a foreign neural network anytime soon.
Realistically, nobody is going to implement this themself. There will be academic applications for now, and eventually something will emerge from NIST’s post-quantum cryptography program that everyone agrees seems right. Once there is agreement on a secure standard, different existing cryptography providers will start to add whatever that is to the package and application developers just need to update make new keys and reencrypt the world.