"software design" entries
Striking parallels between mathematics and software engineering
Becoming more familiar with mathematics will help cross pollinate ideas between mathematics and software engineering.
Editor’s note: Alice Zheng will be part of the team teaching Large-scale Machine Learning Day at Strata + Hadoop World NYC 2015. Visit the Strata + Hadoop World website for more information on the program.
During my first year in graduate school, I had an epiphany about mathematics that changed my whole perspective about the field. I had chosen to study machine learning, a cross-disciplinary research area that combines elements of computer science, statistics, and numerous subfields of mathematics, such as optimization and linear algebra. It was a lot to take in, and all of us first-year students were struggling to absorb the deluge of new concepts.
One night, I was sitting in the office trying to grok linear algebra. A wonderfully lucid textbook served as my guide: Introduction to Linear Algebra, written by Gilbert Strang. But I just wasn’t getting it. I was looking at various definitions — eigen decomposition, Jordan canonical forms, matrix inversions, etc. — and I thought, “Why?” Why does everything look so weird? Why is the inverse defined this way? Come to think of it, why are any of the matrix operations defined the way they are?
While staring at a hopeless wall of symbols, a flash of lightning went off in my mind. I had an insight: math is a design. Prior to that moment, I had approached mathematics as if it were universal truth: transcendent in its perfection, almost unknowable by mere mortals. But on that night, I realized that mathematics is a human-constructed tool. Math is designed, just like software programs are designed, and using many of the same design principles. These principles may not be apparent, but they are comprehensible. In that moment, mathematics went from being unknowable to reasonable. Read more…
Hardware is an elusive constraint on user experience
Andrew “bunnie” Huang on understanding the interplay between software, hardware, and the existing supply chain.
Editor’s note: this interview with Andrew “bunnie” Huang is an excerpt from our recent report, When Hardware Meets Software, by Mike Barlow. The report looks into the new hardware movement, telling its story through the people who are building it. For more stories on the evolving relationship between software and hardware, download the free report.
Andrew “bunnie” Huang has a Ph.D. in electrical engineering from MIT, but he is most famous for reverse engineering the Xbox, establishing his reputation as one of the world’s greatest hardware hackers. He sees an evolving relationship between hardware and software.
“It used to be that products were limited solely by the capability of their hardware. Early radios, for example, had mechanical buttons that acted directly on the physics of the receiver,” says Huang. “As hardware becomes more capable, the user experience of the hardware is more dictated by the software that runs on it. Now that hardware is ridiculously capable — you basically have supercomputers in your pockets that cost next to nothing — pretty much the entire user experience of the product is dictated by the software. The hardware simply serves as an elusive constraint on the user experience.”
Hardware is “a cage,” says Huang, and good software developers learn to work within the constraints of the hardware. “When I work with programmers on new products, I take the first prototype, put it on the desk and I say, ‘Welcome to your new cage.’ That’s the reality. There’s a hard wall. But we try to build the cage big enough so there are options for programmers. A quad core Android phone with a gigabyte of memory is a pretty big cage. Sometimes when programmers feel constrained, they’re just being lazy. There’s always more than one way to skin a cat in the software world.” Read more…
The software of regret
Computing should enable us to have richer lives; it shouldn’t become life.
At a recent meeting, Tim O’Reilly, referring to the work of Tristan Harris and Joe Edelman, talked about “software of regret.” It’s a wonderfully poetic phrase that deserves exploring.
For software developers, the software of regret has some very clear meanings. There’s always software that’s written poorly and incurs too much technical debt that is never paid back. There’s the software you wrote before you knew what you were doing, but never had time to fix; the software that you wrote under an inflexible and unrealistic schedule; and those three lines of code that are an awful hack, but you couldn’t get to work any other way.
That’s not what Tim was talking about, though. The software of regret is software that you use for an hour or two, and then hate yourself for using it. Facebook? Candy Crush? Tumblr? Words with Friends? YouTube? Pick your own; they’re fun for a while, but after a couple of hours, you wonder where the evening went and wish you had done something worthwhile. It’s software that only views us as targets for marketing: as views, eyeballs, and clicks. Can we change the metrics? As Edelman says, rather than designing to maximize clicks and page views, can we design to maximize fulfillment? Could Facebook measure friendships nurtured, rather than products liked?
Computing should enable us to have richer lives; it shouldn’t become life. That’s really what the software of regret is all about: taking over your life and preventing you from engaging with a world that is ultimately a lot richer than a flat, but high-resolution, screen. It’s certainly harder to avoid writing the software of regret than it is to avoid writing spaghetti code that will make your life miserable when the bug reports start rolling in. But probably more important. Do stuff that matters.
Designing resilient communities
Establishing an effective organization for large-scale growth
In the open source and free software movement, we always exalt community, and say the people coding and supporting the software are more valuable than the software itself. Few communities have planned and philosophized as much about community-building as ZeroMQ. In the following posting, Pieter Hintjens quotes from his book ZeroMQ, talking about how he designed the community that works on this messaging library.
How to Make Really Large Architectures (excerpted from ZeroMQ by Pieter Hintjens)
There are, it has been said (at least by people reading this sentence out loud), two ways to make really large-scale software. Option One is to throw massive amounts of money and problems at empires of smart people, and hope that what emerges is not yet another career killer. If you’re very lucky and are building on lots of experience, have kept your teams solid, and are not aiming for technical brilliance, and are furthermore incredibly lucky, it works.
But gambling with hundreds of millions of others’ money isn’t for everyone. For the rest of us who want to build large-scale software, there’s Option Two, which is open source, and more specifically, free software. If you’re asking how the choice of software license is relevant to the scale of the software you build, that’s the right question.
The brilliant and visionary Eben Moglen once said, roughly, that a free software license is the contract on which a community builds. When I heard this, about ten years ago, the idea came to me—Can we deliberately grow free software communities?
Code Simplicity: The science of software design
Learn to be a better programmer by taking charge of your interests
If you want to be a better programmer, a good first step would be to choose an area of software development to take additional responsibility for. Now, when we say “responsibility,” we don’t mean the sort of “you’re to blame and you accept it” responsibility that is so commonly thought of. Instead, we mean the willingness to take charge or the willingness to do something about an area.
So select out some area of software development, and decide to be a bit more responsible for it than one was before. The “area” could be simply some additional part of the current project you work on, the whole project itself, some type of software development that you haven’t done before, some aspect of software development you’d like to know more about, etc. If you’re feeling adventurous, try deciding that you’re personally responsible for the quality of the entire software project you’re working on. If you do, you may be surprised at how much easier this makes your life. When you’re trying to maintain the quality of only a piece of a software project, it’s very difficult. You’re surrounded by complexity or confusion, and you have to fend it off at every turn. But when you look at the project as a whole instead and try to decide what should be done with it as a whole, the solution presents itself much more readily. Now, it may seem like quite a bit more work to resolve the problems of the whole project, and it is. But it’s considerably more satisfying, tremendously more effective, and will bring you up to seniority as a software developer much more quickly than just trying to solve the problems of your one particular area.
The rewards of simple code
"Code Simplicity" author Max Kanat-Alexander on the elegance and utility of simple code.
Simple code is born from planning, discipline and grinding work. But as author Max Kanat-Alexander notes in this interview, the benefits of simple code are worth the considerable effort it requires.
You ain't gonna need what?
One of the defining characteristics of the Rails movement has been its willingness to throw out the rules by which software developers and consultants have typically worked. Those rules typically produce big, overblown projects laden with features that no one ever uses–but which sounded good during the project specification phase. Build the simplest thing that could possibly work, and…