Agile Zone is brought to you in partnership with:

Software Developer, Mentor, Architect and UX/UI craftsman. Also, a psychology nut that loves curling. Zac is a DZone MVB and is not an employee of DZone and has posted 66 posts at DZone. You can read more from them at their website. View Full User Profile

10 Realizations About Developing in a Business

09.06.2013
| 6786 views |
  • submit to reddit
The great philosopher Heraclitus is most notably known by the phrase "Nothing endures but change." This phrase is more commonly known as "The only constant is change." If software development had subtitles, this phrase would accompany it to perfection. With the vast amount of changes to technology and languages, the non-technical lessons of development can get lost. As developers enter the work force, they quickly begin to realize that being paid to do a job is different than programming as a hobby. These distinguishing characteristics separate the "work" development from the "book/school" programming. The following is a series of realizations (in no particular order) about working for a business and developing:
  1. In most circumstances, it's the little things "done right" that make the difference. Achieving deadlines, completing code with minimal bugs, and releasing bug-free software helps to raise confidence in outside stakeholders. Releasing 10 small enhancements without interruption versus one large distributive change always wins in the long run.
  2. Saying "yes" to one thing means "no" to another. This might seem like a no-brainer, but the second part is not always recognized. In business, time is money. Deciding to work on an enhancement or bug must consciously translate into the reality that it takes priority over other work.
  3. Actively identify and accept feature/software obsolescence. From the moment a new technology or feature is released, the clock is ticking. It's important to be proactive toward this concept and plan accordingly. Microsoft is an example of a software company with a proven history of deprecating functionality and eliminating support over time.
  4. Follow the "put in the big rocks first" approach. Do not shy away from the hard or difficult tasks in a project. Tackle those areas first. This will help identify problems early and provide better estimates for remaining work (as smaller items are easier to estimate).
  5. With code and software features, separate the "gotta haves" from the "nice to haves." Most projects admittedly have both. Be pragmatic about the proper category for each item. As deadlines approach, this is invaluable for determining a minimally viable path.
  6. In regards to feature requests, champion assimilation as much as possible. A big budget or lengthy project will raise the eyebrow of any executive. Start by accommodating the request within the current code and architecture. Consciously move beyond that only when absolutely necessary and actively over-communicate that decision.
  7. Skills take years to harden, but mastering patience is a life-long journey. In a profession with broad opinions, varying personalities, and constant deadlines, being patient and mindful of others is paramount. Software development is about more than lines of code.
  8. Do not discount or disrespect aspects of a job. Passing judgment on tasks can cloud opportunity. These include identifying areas of improvement, becoming a material expert, and expanding one's ability for or knowledge of a given topic.
  9. Never stop striving for "the right way." Many companies choose "right now" over the "right decision." Respecting that decision is important, but it should not impede continuous education about the risks involved. Developers are hired for their expertise as much as their ability.
  10. Consciously revisit process, code and functionality. Anything ignored will become the standard. Adopting concepts such as Agile and Lean development can help. Additionally, categorizing and tracking technical debt can improve visibility and provide points of discussion.


Published at DZone with permission of Zac Gery, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)