As a developer working in an enterprise environment, maintaining a solid code base and steady pace of development without having to go back and change the code every time a new design of the same feature comes down the wire gets pretty frustrating. Are you scratching your head wondering if there is a solution to stop the headaches and frustrations of a waterfall methodology? The answer is yes, three words sum it up, iterative driven development. This talk will focus on iterative driven development over incremental development, the differences between the two, how it is best used in large teams working on the same application, and how to not go crazy in the process.
Working as a front-end developer for a large organization is not a walk in the park by any means. There are enhancements to be made, bugs to fix, and knowledge to be shared. Being a developer, writing all the code per the specs comes natural. We as developers want to see the design come to life and we do all we can to make that happen.
But, what do you do when a week later, the design changes? If not a big change, a small change. The color of the heading changes here, or the padding is 10 more pixels to the left? Frustration sets in and you wish there was a more efficient system in place to write code and ship it and be done with it. Taking annotated mockups and building the code to make them work, only to have it completely change the next week is tiresome.
Iterative driven development is not a new thing, but something we as developers should embrace in a large scale corporation that still has yet to adopt an agile methodology of delivering timely, small solutions. By providing code and examples I will show how writing code iterativley will save time and money in the long run.