website statistics Getting Real: The Smarter, Faster, Easier Way to Build a Web Application - PDF Books Online
Hot Best Seller

Getting Real: The Smarter, Faster, Easier Way to Build a Web Application

Availability: Ready to download

Book report Getting Real is the business, design, programming, and marketing philosophies of 37signals — a developer of web-based software used by over 1 million people and businesses in 70 countries. Why is the book relevant? 37signals used the unconventional Getting Real process to launch five successful web-based applications (Basecamp, Campfire, Backpack, Writeboard, Ta-d Book report Getting Real is the business, design, programming, and marketing philosophies of 37signals — a developer of web-based software used by over 1 million people and businesses in 70 countries. Why is the book relevant? 37signals used the unconventional Getting Real process to launch five successful web-based applications (Basecamp, Campfire, Backpack, Writeboard, Ta-da List), and Ruby on Rails, an open-source web application framework, in just two years with no funding, no debt, and only 7 people. What's in it for me? Anyone working on a web app — including entrepreneurs, designers, programmers, executives, or marketers — will find value, fresh perspectives, and inspiration in this practical book. At under 200 pages it's quick reading too. Makes a great airplane book.


Compare

Book report Getting Real is the business, design, programming, and marketing philosophies of 37signals — a developer of web-based software used by over 1 million people and businesses in 70 countries. Why is the book relevant? 37signals used the unconventional Getting Real process to launch five successful web-based applications (Basecamp, Campfire, Backpack, Writeboard, Ta-d Book report Getting Real is the business, design, programming, and marketing philosophies of 37signals — a developer of web-based software used by over 1 million people and businesses in 70 countries. Why is the book relevant? 37signals used the unconventional Getting Real process to launch five successful web-based applications (Basecamp, Campfire, Backpack, Writeboard, Ta-da List), and Ruby on Rails, an open-source web application framework, in just two years with no funding, no debt, and only 7 people. What's in it for me? Anyone working on a web app — including entrepreneurs, designers, programmers, executives, or marketers — will find value, fresh perspectives, and inspiration in this practical book. At under 200 pages it's quick reading too. Makes a great airplane book.

30 review for Getting Real: The Smarter, Faster, Easier Way to Build a Web Application

  1. 4 out of 5

    Arjen

    Unlike their Re-work book, this book actually makes sense. It's kind of a set of 'best practices' on how to efficiently build a web application. I would even claim that many of the advice could be successfully applied outside the web application or even software domain. The book is organised in 'themes' like 'Organisation', 'Code', 'Process', 'Feature Selection' and offers practical, actionable 2 page tips in the form of elaborated aphorisms (did that sentence make it any clearer how this book i Unlike their Re-work book, this book actually makes sense. It's kind of a set of 'best practices' on how to efficiently build a web application. I would even claim that many of the advice could be successfully applied outside the web application or even software domain. The book is organised in 'themes' like 'Organisation', 'Code', 'Process', 'Feature Selection' and offers practical, actionable 2 page tips in the form of elaborated aphorisms (did that sentence make it any clearer how this book is organised?). Almost all the tips heavily lean on agile, scrum, lean, kanban theory and I think that is the strength but also the weakness of the book. The strength is that if you're familiar with agile concepts, the tips in the book work like a trigger. The weakness is that if you're NOT familiar with agile concepts, it's easy to misinterpret the tips or apply them in the wrong context. Highly recommended but only if you are familiar with the agile thing (or you could use this book as your entry into the agile world). I would distributed these freely among my team / institute / organisation / whatever if I were in any position of influence.

  2. 4 out of 5

    Yevgeniy Brikman

    Very quick read, but not a particularly good one. The advice is extremely simplistic, bordering on platitudes, and much of it is not particularly actionable. A lot of it simply does not apply to *many* companies: e.g. building for yourself is all it takes to find a market (tell that to the many engineers who built something that *only* they would want), everything can be self-funded (many business cannot), everyone should give away all of their data for free (unless, of course, data is your diff Very quick read, but not a particularly good one. The advice is extremely simplistic, bordering on platitudes, and much of it is not particularly actionable. A lot of it simply does not apply to *many* companies: e.g. building for yourself is all it takes to find a market (tell that to the many engineers who built something that *only* they would want), everything can be self-funded (many business cannot), everyone should give away all of their data for free (unless, of course, data is your differentiator, which it is for many companies). It's not all bad, of course. The advice on design is actually quite good, mostly because it sticks with very concrete details: e.g. avoid too many preferences/settings in an app, design for regular, blank, and error states, copywriting is part of the design, and that your app has a voice. And some of the quotes from third parties are decent too. Overall, there is some good stuff in this book, but it doesn't do a very good job of presenting it. Some quotes that I liked: Build half a product, not a half-ass product The best designers and the best programmers aren’t the ones with the best skills, or the nimblest fingers, or the ones who can rock and roll with Photoshop or their environment of choice, they are the ones that can determine what just doesn’t matter. That’s where the real gains are made. Most of the time you spend is wasted on things that just don’t matter. If you can cut out the work and thinking that just don’t matter, you’ll achieve productivity you’ve never imagined. Another reason to design first is that the interface is your product. What people see is what you’re selling. If you just slap an interface on at the end, the gaps will show. Design for regular, blank, and error states. The customer decides if an application is worthy at this blank slate stage – the stage when there’s the least amount of information, design, and content on which to judge the overall usefulness of the application. When you fail to design an adequate blank slate, people don’t know what they are missing because everything is missing. Copywriting is interface design. Great interfaces are written. If you think every pixel, every icon, every typeface matters, then you also need to believe every letter matters. Encourage programmers to make counteroffers.You want to hear: “The way you suggested will take 12 hours. But there’s a way I can do it that will only take one hour. It won’t do x but it will do y.” Lorem ipsum changes the way copy is viewed. It reduces text-based content to a visual design element – a shape of text – instead of what it should be: valuable information someone is going to have to enter and/or read. Dummy text means you won’t see the inevitable variations that show up once real information is entered. It means you won’t know what it’s like to fill out forms on your site. Dummy text is a veil between you and reality. Think of your product as a person. What type of person do you want it to be? Polite? Stern? Forgiving? Strict? Funny? Deadpan? Serious? Loose? Do you want to come off as paranoid or trust- ing? As a know-it-all? Or modest and likable? Once you decide, always keep those personality traits in mind as the product is built. Use them to guide the copywriting, the interface, and the feature set. Whenever you make a change, ask yourself if that change fits your app’s personality. Your product has a voice – and it’s talking to your customers 24 hours a day.

  3. 4 out of 5

    Milhouse Van Houten

    Good

  4. 4 out of 5

    Ro

    First of all, you can read this for yourself, online, for free. That spoke to me... Here's the link: http://gettingreal.37signals.com/toc.php... This book is written by the software development team that built Basecamp, Backpack, and Campfire. They are successful, opinionated, and have soom good ideas. Now their business is software development, which is different from instructional design, but it is on some ways analogous. Both involve creativity and technical expertise, teams, budgets and typica First of all, you can read this for yourself, online, for free. That spoke to me... Here's the link: http://gettingreal.37signals.com/toc.php... This book is written by the software development team that built Basecamp, Backpack, and Campfire. They are successful, opinionated, and have soom good ideas. Now their business is software development, which is different from instructional design, but it is on some ways analogous. Both involve creativity and technical expertise, teams, budgets and typically short time lines. Part of the appeal of this book is that the essays are short, pithy and keep things real. I am looking forward to their new book called Rework which is coming out early in March 2010. Best ideas gleaned from the book: Small teams: 3 people on a project Meetings are toxic Keeping large chunks of quiet time available for working

  5. 4 out of 5

    Aniruddh Sudharshan

    This was a good introduction to building a product, quick and insightful read.

  6. 4 out of 5

    ArkarAung

    A good book which highlights the traditional rubbish (eg. never ending meeting, paperwork and so on) and points out how to overcome them based on their experience when it comes to build a web application.

  7. 5 out of 5

    نهى خالد

    That was just awesome. It is really helpful in "getting real" with your ideas to turn them into project. I loved how honest Jason is about all steps that might come up. I also loved the quotes mentioned, they all refer to good books/articles. That was just awesome. It is really helpful in "getting real" with your ideas to turn them into project. I loved how honest Jason is about all steps that might come up. I also loved the quotes mentioned, they all refer to good books/articles.

  8. 5 out of 5

    Shawn

    An "agile" project management methodology and a general guide for start ups from the original developers of Ruby on Rails. Short and very well written in plain language. Some of it breaks sharply with conventional project management, but for many projects (especially web projects) ... I think there is a lot of wisdom in this guide. A few highlights: - "Functional specs force you to make the most important decisions when you have the least information" ... so keep specs extremely simple, develop in An "agile" project management methodology and a general guide for start ups from the original developers of Ruby on Rails. Short and very well written in plain language. Some of it breaks sharply with conventional project management, but for many projects (especially web projects) ... I think there is a lot of wisdom in this guide. A few highlights: - "Functional specs force you to make the most important decisions when you have the least information" ... so keep specs extremely simple, develop in iterations, and develop in ways that makes change easy - "Go from brainstorm to sketches to HTML to coding" ... in that order - "Prevent excess paperwork everywhere." "Build, don't write. If you need to explain something, try mocking it up and prototyping it rather than writing a longwinded document. An actual interface or prototype is on its way to becoming a real product." - "Accept that mistakes will happen and realize it's no big deal as long as you can correct them quickly" ... the premise being that if your risk tolerance can be a little higher, then you can cut time and costs significantly - Keep your team small and each version of your project small. Rigorously guard against non-essential features - "Meetings are toxic." Favor emails and IM over meetings - Make developers do their own tech support ("feel the pain") Available for free online at: http://gettingreal.37signals.com/toc....

  9. 5 out of 5

    Jesper van Haaren

    An excellent handbook full of simple guidelines to build and maintain simple and quality products. It's crazy that a 14-year-old book is still so relevant today, especially in such a fast-paced industry. An excellent handbook full of simple guidelines to build and maintain simple and quality products. It's crazy that a 14-year-old book is still so relevant today, especially in such a fast-paced industry.

  10. 4 out of 5

    Rowan

    37 Signals take on how to do business and build products (particularly web software products). Sanctimonious, but it works.

  11. 5 out of 5

    Boni Aditya

    This book is for very very small Niche of Entrepreneurs. If you are an Entrepreneur and you don't want to take funding. If you are an Entrepreneur and want to remain small. If you are an Entrepreneur and you work in the software industry. If you are an Entrepreneur who does not believe in outsourcing and if you are an Entrepreneur and you believe in deliberately staying small. If you are an Entrepreneur and you believe in Bootstratpping and DIY as opposed to finding the experts to do something. S This book is for very very small Niche of Entrepreneurs. If you are an Entrepreneur and you don't want to take funding. If you are an Entrepreneur and want to remain small. If you are an Entrepreneur and you work in the software industry. If you are an Entrepreneur who does not believe in outsourcing and if you are an Entrepreneur and you believe in deliberately staying small. If you are an Entrepreneur and you believe in Bootstratpping and DIY as opposed to finding the experts to do something. So this book is immediately not applicable to 99 percent of the businesses in the market. If you are an Entrepreneur and you exclusively work with products and abhor services. So there are so many IFs before the content in the book becomes applicable to you. These kinds of firms do exist, but they are extremely rare, because this kind of existence is akin to daily circus. There will never be order, and you will keep building while running in a tight budget and with throat slitting deadlines. I know of friends who own such companies, and work in such companies which deliberately resist scaling up or growing big. They are paranoid about losing control and are really careful about taking other people's money. There are two great sins in this world 1. Avoidable Suffering and 2. Unrealized potential The founder of 37 signals have committed both of these capital mistakes. 1. They cause great suffering not only to themselves but also to their employees and their customers. They cause great suffering to themselves since they have to keep learning eternally, i.e. they spend most of their times putting out trivial fires that does not deserve their attention. By refusing to specialize or outsource, they take it upon themselves to DIY everything, which means that they end up doing a lot of maintenance work, so much for Comparative advantage. The Employees also suffer due to lack of specialization of any kind. They would end up becoming generalists, jack of all trades and master of none, and thus actually end up delivering products that eat up all their time and also make them lose their peace. Finally the customers suffer, for there are a lot of features that won't be ever implemented, since the founders are short of time. 2. When founders deliberately keep their operations small, what they don't understand is that they lose the ability to work on great ideas. The scope of ideas they can work with diminishes drastically. They are left with very few silly and trivial problems to solve. Small companies unfortunately can only solve small problems. Thus these companies lose golden opportunities by limiting themselves. One example is Craigslist, by deliberately trying to do less they have let go of the incredible niche that they have created. At one end we see, companies trying to scale globally with Blitzscaling strategies to serve millions and billions of customers and on the other hand we see these companies which deliberately remain small, due to myriad of trivial reasons. This deliberate attempt to control growth reminds me of Bonsai Trees, where the growth is deliberately stunted. Getting real is a deliberate attempt to suppress growth, this is as dangerous as injecting steroids (huge capital) into the product to force growth artificially. Deliberately destroying organic growth under the guise of keeping things simple is absurd. This book is only for such audience who want perfect control and obsess over keeping small and manageable as opposed to exploiting the full range of opportunities they have at their disposal. There is another book which deals with similar genre, SMALL GIANTS, a book that has a collection of all the firms that have made a deliberate choice to remain small as opposed to grow to realize their full potential. The book itself is extremely useful, though the underlying theme is Here is a list of Books that were mentioned in this work. Getting Real Elements of style The pragmatic programmer Signal vs noise Be a better liar Less is more - jump starting productivity with small teams Why software is the way it is Make mantra 16 ignored details - guy kawasaki Scaling up in startup’s - abasanjo Free software and good user interfaces havoc pennington Agile web development with rails The productivity and software guide - life hacker, Gina tripani Don’t let meetings rule - Lisa heinberg How to find and keep the perfect VA Defensive design for the web Church of the customer blog What is customer Evangelism

  12. 4 out of 5

    Leena S N

    One of the books that every software professional should read regardless of their role. "Less is more" the mantra repeated throughout the book along with the techniques to achieve the same by keeping things simple and small. One of the books that every software professional should read regardless of their role. "Less is more" the mantra repeated throughout the book along with the techniques to achieve the same by keeping things simple and small.

  13. 5 out of 5

    Matt

    If you're already reading info from other small entrepreneurs, then the content of this book is not very surprising. It's solid advice for anyone interested in staying small and focused in software business. If you're already reading info from other small entrepreneurs, then the content of this book is not very surprising. It's solid advice for anyone interested in staying small and focused in software business.

  14. 4 out of 5

    Gaurang Varshney

    Getting Real is not just for web but for any kind of product for which you have an opportunity to build in agile. this guide would evolve your insights to develop minimal and more realistic product.

  15. 4 out of 5

    Mohit Khare

    Overall a nice guide for building saas products. I wish I would have read this before my first launch. It did provide a simplistic view but it's not always that straight forward. In case you are building new saas business - go and read this. Overall a nice guide for building saas products. I wish I would have read this before my first launch. It did provide a simplistic view but it's not always that straight forward. In case you are building new saas business - go and read this.

  16. 5 out of 5

    Wouter

    Given you never read Rework or the $100 startup and you're not familiar to scrum or eXtreme Programming practices, only then this book will inspire you and open your eyes. Otherwise it's a nice rehash but there's nothing new under the sun. Scratch your own itch, meetings are toxic, release early and often, watch out for code complexity, ... - some things are literally found again in "Rework", but I did read Rework first so I might lower that rating too ;-) It's quite a quick read and that's a go Given you never read Rework or the $100 startup and you're not familiar to scrum or eXtreme Programming practices, only then this book will inspire you and open your eyes. Otherwise it's a nice rehash but there's nothing new under the sun. Scratch your own itch, meetings are toxic, release early and often, watch out for code complexity, ... - some things are literally found again in "Rework", but I did read Rework first so I might lower that rating too ;-) It's quite a quick read and that's a good thing. Every time you're struck on something, it's nice to flip through the table of contents, but nothing more.

  17. 5 out of 5

    Matt Langan

    This book is worth its weight in gold. Simply put, it is all business. Each chapter is crafted in digestible, highly valuable chunks. It's free of fluff and business jargon, which is unlike most business books out there that basically say the same thing in a thousand different ways. Internet/software entrepreneurs will appreciate this book more than folks in corporate environments, but we could all learn a lot from the tips it shares. Highly recommend! This book is worth its weight in gold. Simply put, it is all business. Each chapter is crafted in digestible, highly valuable chunks. It's free of fluff and business jargon, which is unlike most business books out there that basically say the same thing in a thousand different ways. Internet/software entrepreneurs will appreciate this book more than folks in corporate environments, but we could all learn a lot from the tips it shares. Highly recommend!

  18. 4 out of 5

    Janet Richards

    Great ideas - although I'm not a web designer - many of the ideas apply to what I do - corporate training. Basically - do more, think about doing more a lot less. I 100% agree - more and more I feel like I'm documenting what I'm going to do, meeting about what I'm going to do, and telling managers what I'm going to do than I get time to do it! :) This book is ammo to stop doing that! Great ideas - although I'm not a web designer - many of the ideas apply to what I do - corporate training. Basically - do more, think about doing more a lot less. I 100% agree - more and more I feel like I'm documenting what I'm going to do, meeting about what I'm going to do, and telling managers what I'm going to do than I get time to do it! :) This book is ammo to stop doing that!

  19. 5 out of 5

    César Frick

    It's a really interesting book, if you understand that it's the 37Signals perspective and there are some things that could work for you and other that couldn't. It's not just for the "entrepreneur", but for anybody who wants to push his/her work to a new level without (and I think this is one of the most important attributes of the book) all the "entrepreneur crap" you usually get everywhere It's a really interesting book, if you understand that it's the 37Signals perspective and there are some things that could work for you and other that couldn't. It's not just for the "entrepreneur", but for anybody who wants to push his/her work to a new level without (and I think this is one of the most important attributes of the book) all the "entrepreneur crap" you usually get everywhere

  20. 4 out of 5

    Oana Sipos

    Getting Real is about programming. And in my view, it was also about life and common-sense. I would highly recommend it to anybody interested in programming (of any kind) and those who want to develop something bigger in this direction. Light read and condensed good pieces of advice.

  21. 5 out of 5

    Sundeep

    good book...quick read...very in line with my way of thinking about startups (move quickly, etc.)

  22. 4 out of 5

    Mazen Aldarrab

    Easy to read , Easy to understand - to the point !

  23. 5 out of 5

    Steven

    The better, faster, no BS way to build a web application.

  24. 5 out of 5

    Andrea

    This review has been hidden because it contains spoilers. To view it, click here. Generally helpful but MAJOR disagreement with one point - something I hear far too often in our new sick corporate capitalist world. Derek Sivers asinine & unscrupulous quote: "It's so funny when I hear people being so protective of ideas. (People who want me to sign an NDA to tell me the simplest idea.) To me, ideas are worth nothing until executed. They are just a multiplier. Execution is worth millions." I'm sorry, but when petty condescension towards "little ideas" turns in to YOU making mil Generally helpful but MAJOR disagreement with one point - something I hear far too often in our new sick corporate capitalist world. Derek Sivers asinine & unscrupulous quote: "It's so funny when I hear people being so protective of ideas. (People who want me to sign an NDA to tell me the simplest idea.) To me, ideas are worth nothing until executed. They are just a multiplier. Execution is worth millions." I'm sorry, but when petty condescension towards "little ideas" turns in to YOU making millions off someone else's idea, that someone else deserves half that money. The very idea that the idea is meaningless until executed is so deeply unethical. Especially when the executed product would not exist without the idea. Heinous. I have an app I'm working on, alone, using online software. The owner of the site emailed me asking why I'd not been online in a while. We actually had a back and forth exchange via email and he suggested that possibly, based on the merit of my app idea, we could change all my monthly payments from me doing it all, in to their designers doing it for a fee. It took a while but I finally trusted him with my unique idea which I'd told noone about. After that....silence. I emailed again asking what he'd thought and he responded that they have a lot going on, he's busy and can't always reply to every exchange....... No other feedback. Its been months. This was after a good 6-7 emails exchanged. And yes, it is an unique and widely needed concept for the healthcare field. Due diligence done, there is nothing like it. If anything like my app appears out there I'm going to investigate thoroughly to see if he has ANY connection to it, and then sue the company for theft of intellectual property. Aside from that...decent book with good suggestions.

  25. 5 out of 5

    Lars K Jensen

    This book was written back in 2006, before Agile and Scrum and other frameworks really took off and gained popularity. The team behind it were called 37signals at the time, now they are just caled Basecamp - named after their most popular product. With that in mind, I was totally surprised at how readable and enjoyable this book still is 12 years after its publication. That is no small feat in the field of digital product development. The book is written like a manifest with very short chapters (s This book was written back in 2006, before Agile and Scrum and other frameworks really took off and gained popularity. The team behind it were called 37signals at the time, now they are just caled Basecamp - named after their most popular product. With that in mind, I was totally surprised at how readable and enjoyable this book still is 12 years after its publication. That is no small feat in the field of digital product development. The book is written like a manifest with very short chapters (some of them only one page) and in clear-cut language. There is no messing about here - and no grey zones as well. As I said, think of it as a manifest. And in some places as a manual. One of the main points in the book is "start small and scale later" - and as someone who is almost obsessed with scale and making things scalable, I needed to read this book :) The sub-title of the book is "The smarter, faster, easier way to build a successful web application" but I would recommend reading it even if you don't work with building web applications. What has happened since 2006 is that some of the methods from programming and technical development have spread to all digital development. So, if you are involved in product development (and/or building, obviously) make sure you read this book. It's like a bag of candy; you don't really want it to stop. If you're interested, you can get a free PDF copy of 'Getting Real' by signing up for the Basecamp newsletter: https://basecamp.com/books/getting-real

  26. 4 out of 5

    Eduardo Donato

    First of all, this is a book from 2006. Twelve years ago, some ideas from this book were really disruptive and Agile was becoming the de facto standard in Software Development. So, if you read it now the majority of the ideas will seem obvious. But there are still some practices that are not followed in every tech company. The one thing I didn't like was the fact that the book is a collection of cards, in which there is no continuity. All the ideas are superficial and some of these ideas appear First of all, this is a book from 2006. Twelve years ago, some ideas from this book were really disruptive and Agile was becoming the de facto standard in Software Development. So, if you read it now the majority of the ideas will seem obvious. But there are still some practices that are not followed in every tech company. The one thing I didn't like was the fact that the book is a collection of cards, in which there is no continuity. All the ideas are superficial and some of these ideas appear in several cards. Despite that, my colleagues from work and I read this book and discussed how we could apply some of the ideas in our day to day process. This was a big difference and everyone enjoyed these discussions.

  27. 5 out of 5

    Chad Warner

    The book is written for those who create web applications, but as a web designer who creates WordPress websites, I found plenty of relevant advice about planning, project management, client relations, hiring, and productivity. The 37 Signals authors make many similar points in Rework. You can download the book for free. Introduction “Months of planning are not necessary. Months of writing specs are not necessary – specs should have the foundations nailed and details figured out and refined during t The book is written for those who create web applications, but as a web designer who creates WordPress websites, I found plenty of relevant advice about planning, project management, client relations, hiring, and productivity. The 37 Signals authors make many similar points in Rework. You can download the book for free. Introduction “Months of planning are not necessary. Months of writing specs are not necessary – specs should have the foundations nailed and details figured out and refined during the development phase. Don’t try to close all open issues and nail every single detail before development starts.” Fix Time and Budget, Flex Scope “Here’s an easy way to launch on time and on budget: keep them fixed. Never throw more time or money at a problem, just scale back the scope.” It’s a Problem When It’s a Problem • “People often spend too much time up front trying to solve problems they don’t even have yet.” • “Don’t sweat stuff until you actually must. Don’t overbuild.” • “Make decisions just in time, when you have access to the real information you need. In the meanwhile, you’ll be able to lavish attention on the things that require immediate care.” It Just Doesn’t Matter • “The best designers and the best programmers aren’t the ones with the best skills… they are the ones that can determine what just doesn’t matter. That’s where the real gains are made.” • “Most of the time you spend is wasted on things that just don’t matter. If you can cut out the work and thinking that just don’t matter, you’ll achieve productivity you’ve never imagined.” From Idea to Implementation “Go from brainstorm to sketches to HTML to coding.” 1. Brainstorm: “What does the app need to do? How will we know when it’s useful? What exactly are we going to make?” 2. Sketches: “Draw stuff. Scrawl stuff. Boxes, circles, lines. Get your ideas out of your head and onto paper. The goal at this point should be to convert concepts into rough interface designs.” 3. HTML: “Get something real posted so everyone can see what it looks like on screen.” “Don’t write any programming code yet. Just build a mock-up in HTML and CSS.” 4. Code: “When the mock-up looks good and demonstrates enough of the necessary functionality, go ahead and plug in the programming code.” Shrink Your Time • “Estimates that stretch into weeks or months are fantasies.” • “Keep breaking down timeframes into smaller chunks. Instead of a 12 week project, think of it as 12 weeklong projects. Instead of guesstimating at tasks that take 30+ hours, break them down into more realistic 6-10 hour chunks. Then proceed one step at a time.” • “Smaller tasks and smaller timelines are more manageable, hide fewer possible requirement misunderstandings, and cost less to change your mind about or re- do. Smaller timelines keep developers engaged…” • “Next time someone tries to pin you down for an exact answer to an unknowable question – whether it’s for a deadline date, a final project cost… say ‘I don’t know… [Reframe] the question as a collaborative conversation. By learning how exact your estimate needs to be (and why), you can work together.” Hire Less and Hire Later • “Don’t hire people. Look for another way. Is the work that’s burdening you really necessary? What if you just don’t do it? Can you solve the problem with a slice of software or a change of practice instead?” • “If there’s no other way, then consider a hire. But you should know exactly who to get, how to introduce them to the work, and the exact pain you expect them to relieve.” Get Well Rounded Individuals • “Go for quick learning generalists over ingrained specialists.” • “Small teams need people who can wear different hats.” Wordsmiths • “If you are trying to decide between… people to fill a position, always hire the better writer.” • “Being a good writer is about more than words. Good writers know how to communicate. They make things easy to understand. They can put themselves in someone else’s shoes. They know what to omit. They think clearly.” There’s Nothing Functional about a Functional Spec • “Functional specs force you to make the most important decisions when you have the least information.” • “The more you build it, the more you use it, the more you know it. That’s when you should be making decisions – when you have more information, not less.” • “Functional specs don’t let you evolve, change, and reassess.” • “Go with a briefer alternative that moves you toward something real. Write a one page story about what the app needs to do. Use plain language and make it quick. If it takes more than a page to explain it, then it’s too complex.” Then proceed as described in From Idea to Implementation. Misc. • “Make half the day alone time.” Avoid communication and just work. • “Build, don’t write. If you need to explain something, try mocking it up and prototyping it rather than writing a long- winded document.” • “Avoid building walls between your customers and the development/design team. Don’t outsource customer support to a call center or third party. Do it yourself. You, and your whole team, should know what your customers are saying.” • “Prioritize your bugs.” “Most bugs are annoying, not destroying. Annoyances can be tabled for a bit.”

  28. 5 out of 5

    Swateek

    Finishing a book within a day after so many days! It was literally 'unputdownable'. A book about how Web Apps should get real, how developers should treat them through the dev cycle, and while handling their after release cycles. This book appealed to me particularly because of similar challenges I face at work almost every day and it was interesting I recollected all those discussions that we have had had over those issues faced then. This was kind of a walk through my memory over the past 5 yea Finishing a book within a day after so many days! It was literally 'unputdownable'. A book about how Web Apps should get real, how developers should treat them through the dev cycle, and while handling their after release cycles. This book appealed to me particularly because of similar challenges I face at work almost every day and it was interesting I recollected all those discussions that we have had had over those issues faced then. This was kind of a walk through my memory over the past 5 years of work. Loved reading this!

  29. 5 out of 5

    Pushkar

    Although it's an old pick but the reason why I went for this book coz I just fall in love with the book from the same organization(37signal) "Rework" and the blog that they regularly update named SignalvsNoise. I recommend checking that blog, it's really cool and this book, if you're into some trap of startup thing and it might help you be a programmer as well, coz this is the organization responsible for Ruby on Rails and they do have something to say through this one. Definately recommend readin Although it's an old pick but the reason why I went for this book coz I just fall in love with the book from the same organization(37signal) "Rework" and the blog that they regularly update named SignalvsNoise. I recommend checking that blog, it's really cool and this book, if you're into some trap of startup thing and it might help you be a programmer as well, coz this is the organization responsible for Ruby on Rails and they do have something to say through this one. Definately recommend reading this one.

  30. 5 out of 5

    Marcus Kazmierczak

    A good quick read around product development practices. It was written in 2006, the PDF has been sitting in my ebooks folder for over 10 years. Amazingly, for a book about web development, released prior to the iPhone, it is still quite relevant and good pracitical advice. The book did not provide me with anything earth shaking, especially if you've been doing app development for awhile; but it is good a collection of still sound principles and reasoning for modern development processes, and pro A good quick read around product development practices. It was written in 2006, the PDF has been sitting in my ebooks folder for over 10 years. Amazingly, for a book about web development, released prior to the iPhone, it is still quite relevant and good pracitical advice. The book did not provide me with anything earth shaking, especially if you've been doing app development for awhile; but it is good a collection of still sound principles and reasoning for modern development processes, and project management.

Add a review

Your email address will not be published. Required fields are marked *

Loading...
We use cookies to give you the best online experience. By using our website you agree to our use of cookies in accordance with our cookie policy.