Pezely's
Posits

Observations from over thirty years in the software industry—
a blending of computer science, psychology and philosophy

  1. Conceptually, add or change only one thing at a time in a release, else confuse your customers or collaborators.
  2. Make rapid, iterative releases— a.k.a., "release early, release often"— even if only for internal purposes such as a candidate for official deployment.
  3. Many good writers advise show, don't tell, and so with software: construct enough to illustrate the most unique elements first as proof-of-concept.
  4. Write the hardest parts first. Some explain this as, "if you're going to fail, do it quickly," so you may then more intelligently begin again with wisdom gained from that experience or move on to what's next.
  5. The best program is one you don't have to write: put a shell script around an existing app, fork an existing library, delegate...
  6. Writing software is creating a universe with its own intrinsic nature, so respect that, explore it, and maybe you'll discover something new.
  7. There are people appropriate to start something new, to bring it to maturity, to be caregiver for its continued existence, but rarely is it the same group of people fulfilling each of those roles over time. Experience all of them to understand where your talents lend themselves best.
  8. Being entrepreneurial doesn't require you to be CEO. Instead, everyone in an early stage upstart organization must equally understand efficiencies and trade-offs required to attain the next level, and that is the true wisdom of being entrepreneurial.
  9. You are continually, simultaneously both student and teacher— at the same moment.
  10. Anger or any other strong emotion is a signal that there's something in that situation you'd do well to stop and objectively learn.
  11. Openly share knowledge and ways of understanding, and discover that when you're the one in need, the right answer is easily available.
  12. If you weren't there, refrain from criticizing decisions or outcome, but do suggests paths for improvement in a nonjudgmental way.
  13. The difference between criticism versus critique is that the latter is actionable. Always offer the constructive version.
  14. Nothing exists in isolation: technology, skills, business plans, people, etc., are so interconnected that you'd do well to consider this a law of nature, and enjoy discovering those connections!
  15. On ideas: Give it all you've got and more. Hold nothing back, then more will flow.
  16. Of body: be good to your body (the meat), and it'll be good to you. Take eye breaks. Remember to breathe. Minimize stimulants. Go for short walks periodically in addition to after lunch and in mid-afternoon.
  17. Just because it's new, doesn't mean it's better— just less accumulated entropy.
  18. As with natural languages, studying programming languages that are new to you improves versatility because each potentially offers something unique, a different way of expressing and emphasizing an area for which you would do well to focus.
  19. True genius is being humble enough to admit not knowing and the clarity of asking meaningful questions.
  20. Reinventing the wheel isn't necessarily bad, just usually excessive.
  21. But when reinventing that wheel, start with a fresh look at the physics too.
  22. A software system that is complicated isn't the same as having complexity. A trivial program could be written as unreadable spaghetti code, yet massive systems have maintained elegance of design while addressing challenges previously believed impossible.
  23. Criteria are distinctly different than requirements, and both are necessary. Well-defined criteria offer high-level, abstract concepts for understanding the actual problems and recognizing the correct solution. Well-written requirements are concrete terms that are unambiguous and clearly articulate when a particular feature may be declared as done.
  24. State-machines nearly always exist within software systems, so take time to design these carefully (else be implicit, poorly documented and leading to much confusion when using or maintaining the system).
  25. Complexity may be shifted from one layer or component to another but never really goes away.
  26. However, complexity may be consolidated (rather than duplicating the same bit of functionality throughout the system).
  27. Also consider complexity of new staff having to learn your system, and factor this into your design criteria.
  28. Let computers do the multi-tasking, but if you must: one may perhaps wear three "hats" yet only if all tasks are inter-related such as dev, ops and tech writing; or leadership, strategy and management; but not management, dev and support.
  29. For agility in software systems, favour dataflow over workflow within the system itself: advancing through the pipeline with small incremental transformations that minimize or eliminate side-effects.
  30. Understand dataflow to be like a river following its natural course or like the architect/builder who paved paths between structures on a new college campus only after observing direction and width of wear patterns in the grass.
  31. Accommodating dataflow is like a waterwheel driving a mill on the riverbank and otherwise leaves majority of the environment undisturbed; whereas, enforcing workflow is like a dam which either requires significantly more effort to facilitate salmon returning to spawn or shortsightedly ignores its impact on anything else.
  32. Frameworks strictly enforce workflow and should be avoided unless your scenario exactly matches those predetermined patterns.
  33. On the other hand— like books at a lending library— software libraries may be used how you see fit: read the book backwards or read only one page. Invoke functions in whatever sequence applies to your unique conditions.
  34. Frameworks may facilitate reaching 50% or even 70% completion very quickly but rarely attaining 90%. However, functional libraries tend to accommodate recombining, such that a little more investment during early stages greatly increases chances of reaching 100% and generally enables going far beyond initial criteria.
  35. When considering a rewrite or performance enhancement that might bring merely 2x or 5x improvement, make this the lowest priority because it might be a waste of time compared to waiting for next generation of equivalent hardware or upgrading to another architecture that offers wider concurrency, better parallelism, or less contention.
  36. For performance improvements, focus only on those that would yield 10x, 100x, or 1000x returns.
  37. Designing a custom system isn't the same as inventing, so arguments citing "not invented here" syndrome would be invalid in this case.
  38. Learn about arguments from fallacy so as to liberate yourself beyond manipulation, allowing healthy conversation and honest debate.
  39. Study the trivium, so then society may catch-up to recent ancestors with "only a fourth grade education."
  40. When functioning as a change agent, respect that not everyone may want the change that you bring or want to change from the status quo. As preemptive measure, it's beneficial for yourself and those directly impacted if you first have buy-in from the highest levels of the respective organization. Get it in writing, if possible.
  41. Sometimes you might find "It's easier to beg forgiveness than to ask permission," but do so only as a last resort.
  42. Instead, find ways to build bridges to people: learn their language, discover their symbols, master their concepts, go deep into their world, and then discover for yourself that change begins from within.
  43. Like a good teacher, an effective manager is one who helps the individual and entire staff ask the right questions as well as find individual answers to those questions that would be appropriate for each.
  44. Effective management removes obstacles, carefully articulates criteria at a business level versus technical, facilitates healthy discussion within and across groups, and it enforces boundaries such as transforming things like "feature creep" into new or changed requirements.
  45. Every organization should have its thought leader as one who places the proverbial stake in the sand and points in a singular direction by which everyone else can be unified as their common goal.
  46. Leadership principles should be either actionable or provide clarity of thought, and these are best worded in the imperative as affirming statements. (Where possible, refrain from expressing what not to do.)
  47. A healthy organization is one built upon mutual respect and consideration.
  48. Respect each individual's contribution by giving them sufficient autonomy based upon relevant skills and experience.
  49. Finding a healthy balance between tenured staff and new blood may be indicated by degree to which a long time employee leaving creates disruption versus the degree to which on-boarding someone new requires indoctrination and "paying your dues." These may be measured by duration, effort required by additional staff and levels of autonomy during the transition.
  50. Sure, you don't need to use Lisp (especially if you're the competition).
  51. Stick around long enough, and history becomes part of your past.
  52. Give yourself time to unplug: just be and allow your higher self to come through.
  53. "... Know when to leave."

By following your own intuition, everything flows from there.




The items above when applied within the context of designing software systems, build upon Dave Mills' maxims.

Copyright © 2006, 2007, 2009, 2014, 2016 Daniel Joseph Pezely.
May be licensed via Creative Commons Attribution.