It’s not every day you open up your “desk drawer of things you should throw out”, and get a reminder of where it all started!
Most times in software development, we like our processes.
It’s nice to know that the web app you’ve just set live actually works. So we have a few processes around writing tests, and hiring QAs to make sure that happens.
But sometimes, the best results are found when you do things a little more creatively.
A great question over on Quora (thanks Khalid!)
Why do large corporations (e.g Quora) decide to write their important applications in python when they know that as the complexity of their code base increases, figuring out the interacting components will be hard?
It’s a great question, and it’s taken me 30 years to figure it out.
I’m a big fan of Martin Fowler’s definition of technical debt, here.
The name refers to the myriad ‘‘do it quick, or do it right’ decisions made by engineers everyday. In software, we have a little more freedom than our friends in Aeronautics to actually ship something that works – but only just. We can always fix it later. With a 747 – not so much.
But just how well does this analogy fit typical software projects?
Related to the tutorial How to do TDD with Java, this video from 2011 discusses how we used TDD with remote pair programming to build Yuuguu.
At my first job, a simple request on a spec led to a really hard problem to solve. How do you get data out of a machine more quickly than you can produce it?
This is how a bit of team work combined three disciplines to find a solution.
Whilst programming is thought to be a purely technical field, it isn’t. People are far more important. And that means we have to get our ideas across to other people clearly, whether in code, in a sales brochure or in a video.
And the way this has always been done best is by telling stories.
But how does that relate to code?