GuiMags look like the nicest way to prototype something before going to HTML and CSS. Labor intensive forms of prototyping don’t seem to add much value, and paper and traditional whiteboard prototyping only works until you’ve changed your mind about something and have to throw your work in the trash or erase half the board.
Although I decided to postpone a magnet purchase until I am doing design again, I was able to get my hands on the book. Its premise: we limit ourselves by the technologies we use. Instead of thinking outside the box, we’re often thinking and functioning in it. A large part of this thinking inside the box is how we develop software.
Although, everyone interested in the topic should pick up the book, here are a few of my takeaways:
- Every major form of art that involves technology (music, film, video games, graphic design) starts outside technology. Artists do not limit themselves by their technology but by the limits of their own minds. As a software engineer, you often limit yourself by the technology you use day-to-day.
- Spend as much time as you can iterating on concept and design before going to implementation.
- Design the software front-end not the back-end first.
- Just like there are code freezes, freeze the product when it has passed the design phase.
- It is often wise to outsource the implementation.
- This serves as a peer review of the design before it goes to implementation. Software developers traditionally think about the back-end first.
- Different cultures have different strengths: “England and Western Europe are great at design, Ukraine and Macedonia have amazing and prompt developers who can think for themselves, the Netherlands always emails back the same day, India is extremely polite, etc.”
- Work can be done while you are sleeping. “This can cut the development time in half.”
- Because you already know what you want and won’t be constantly changing the design, contractors will want to work with you even if you pay less.
- Only be satisfied with five-star developers.
- Pay more than you agree to pay.
- Do one-week sprints. Longer sprints end up getting delayed, with excuses.
With the last (sub)point in mind, I think this methodology is well-suited for an agile development process.
There is a lot to gain from reading the book, so make sure to grab a copy for yourself.