Your SlideShare is downloading. ×
How NOT to Develop ( With WordPress ) - Wcchi 2014
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

How NOT to Develop ( With WordPress ) - Wcchi 2014


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. How NOT to Develop ( With WordPress )
  • 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. 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. 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. Design ● Talk ● With ● Development ● Early ● And ● Often
  • 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. 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. 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. 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. 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. That’s It Thanks for letting me talk Questions? @add_action_dan @alleydev