Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

How NOT to Develop ( With WordPress ) - Wcchi 2014


Published on

  • Be the first to comment

  • Be the first to like this

How NOT to Develop ( With WordPress ) - Wcchi 2014

  1. 1. How NOT to Develop ( With WordPress )
  2. 2. I’m Dan B.S. Applied Sociology - MN ST Mankato 4+ years of Freelance 8 Months at Blue Earth Interactive ( St. Paul ) Currently Software Engineer at Alley Interactive ( NY )
  3. 3. Let’s Get Started: Client Selection Find the GoldiLocks Client! ● Too Hot ○ A project that would require a large team and you’re a one person-shop ● Too Cold ○ A project that has a $500 budget but wants it to ‘go viral’ (http://www. ) ● Just Right ○ Your bread-and-butter but still pushes your skill set
  4. 4. Discovery ● Spend as much time here as needed ● You can charge for discovery ○ This becomes a deliverable in itself, which the client then owns ● Make sure the discovery doc is a working document ● Address change orders appropriately and don't sweat the small stuff ● Project bid should come in a range of hours / $$$ ○ Sometimes line item a contingency budget, sometimes work it into the total cost
  5. 5. Design ● Talk ● With ● Development ● Early ● And ● Often
  6. 6. Design cont... ● Designers should have at least a basic understanding of the platform ○ HTML / CSS ● Some agencies ask designers to code out the front end as well ○ Not sure I agree with this ( ) ● Design NEEDS to be presented in-browser to the client ○ As a JPEG ○ As hard-coded HTML ○ As a coded prototype of the platform ( start putting WP stuff in now )
  7. 7. Development ● Talk with design early and often ● Raise design dev concerns right away ○ 800px tall modals will not work ● Raise development dev concerns right away ○ I.e. - How are we going to pull this off ● WRITE CLEAN CODE FOLLOWING A STANDARD ○ ● Do internal code reviews whenever possible
  8. 8. Development cont... ● Spend time making sure you’re doing_it_right() the first time ○ It’s far better to spend 30 mins thinking / talking about an issue then spending 3.5 hours re-doing it the day before launch ○ Correct usage of div / section / article / aside / etc is important in early development
  9. 9. Delivery ● Have a solid & complete QA process in place ● QA should be done 2-3 weeks before launch ○ This will give you time for changes and QA-ing the changes ● It is better to deliver at 80% functionality with no bugs than 100% functionality with lots-o-bugs ○ It’s important to decide what can go to Phase 2 ● Plan for things not to go smoothly ○ Keep a developer or two available in the weeks following launch for quick fixes
  10. 10. Maintenance ● Set a hard date for when delivery is complete and maintenance starts ● Budgeting Options: ○ Set a monthly limit ■ Usually set by the client’s budget ○ Open hourly billing ■ IF you do this, do weekly summaries of hours spend and dollar amounts ○ Per issue or change order pricing ■ This can turn into the client feeling like they are being nickeled and dimed
  11. 11. That’s It Thanks for letting me talk Questions? @add_action_dan @alleydev