Where are the Patterns?

Software patterns are repeatable techniques. Once you (or someone else) solve a problem, thn reuse the solution as a "pattern" for similar problems.

As developers reuse patterns, they accept them as "proven" techniques to solve common problems. Some proven patterns are DAL, web services, and command/view.

When the developer community shares patterns, they can become a lexicon for discussing problems and thread of consistency between different projects.

What is most important about patterns is that they are solutions; they are not the telltale of good architecture. A project does not need any pattern unless there is first a problem.

It is unlikely a project would implement zero patterns, even the smallest project. Some patterns are so inherent to development that we do not realize or consider them patterns.

To look at a project and BEGIN with an expectation of certain patterns (typically contemporary patterns) is an inexperienced approach to evaluating robustness or architectural quality.

Still, many magazine-educated developers read/learn about new patterns and subsequently evaluate their own code and projects against the presence of those patterns. They criticize the absence of these patterns, or undermining confidence in the existing solution(s).

No one denies that introducing new patterns into old projects can be beneficial. Some patterns supersede old patterns with better techniques. Business value and project costs must drive substantive retrofits more than a desire for the latest thing.

Little should be for the sake of cool – though some things should be.

The solution architect must lay out the system design, and then select patterns to solve anticipated high-level problems. He outlines default patterns to solve lower-level problems that may (or may not) occur – this promotes consistency.

Each developer solves individual problems every day. They use their own patterns that compliment the high-level and project-consistent patterns already in place.

Software patterns emerge as problems emerge. No worthwhile architect starts with the pattern and looks for shoehorn problems.

The next time you see a project and catch yourself wondering where ABC and XYZ patterns are, reconsider if the problem those patterns solves are relevant in the solution's context. Sometimes "simple" is the best pattern an architect or developer can implement.

Project Job Descriptions

[this post is not complete]

Every project has leaders. There are project managers, analyst leads, developer leads, and architects. Each adequately meets their portion of the software development lifecycle. What's somewhat easy is coming up with their job descriptions, what difficult is defining their correct relationships. I thought I would take a moment to try. Introducing project roles Some roles are obvious. Many SDLC methodologies (MSF, XP, Scrum) have gone before us to help. Using these, I will indicate the bare necessities. I do not mean no others may be necessary, but that these are. Executive Sponsor Business Sponsor (or Product Owner/Scrum) Subject Matter Expert (or Stakeholder/Scrum) Business Advocate (or Business Liaison) Project Manager (or Scrum Master/Scrum) Functional Architect (or Lead Analyst) Business Analyst Manual Tester Technical Writer (or User Education Specialist/MSF) Technical Architect (or Solution Architect/MSF) Technical Lead (or Lead Developer) Developer Build Master (or Release Manager/MSF) To be clear, these roles are universal. It doesn't matter if you handle project with waterfall or agile approaches. In order to marshal project efforts, the roles in that list are necessary duties. The all-in-one This begs the question: which roles may be assumed by a single person? Some small (often freelance) projects have one team member. Cost, time, or other factors make this inescapable. In so, I concede roles may be shared – but this does not become a recommendation. The situation is extenuatory, like a single athlete running all the legs of a relay. Sharing roles sheds duties Review the roles list again. Consider the quantity. In medium-sized projects, simple cost makes "sharing-roles" a practical requirement. Here is a small project's "shared" role setup: Executive Sponsor, Business Sponsor, Subject Matter Expert, Business Advocate Project Manager, Functional Architect, Business Analyst, Manual Tester, Technical Writer Technical Architect, Technical Lead Developer, Builder Here, four fill all roles. Whenever two things are merged, something of each is lost. No one expects either to be fully the same, any more than two glasses of water poured into one remains the same volume. What is lost, however, can be selected; job descriptions address this. Role Interaction ORM [image needed] The interaction of different objects (roles) in the project, guide us in selecting which may be shared by a single member. They also help indicate conflict between roles and potential overlap. I am not suggesting that you limit intrapersonal communication. The ORM indicates the duties of communication. Role Organization Chart [image needed] It is difficult to communicate the importance of a project organization chart as part of any project's charter. However, it is. Defining such relationships post-problem is laden with pitfalls and spawns issues deeply set in human personality. The project charter sets expectations and settles the matter. Apparent authority Now consider who directs whom, how decisions are made, and how ties are broken. Although the final authority lies in the Executive Sponsor, and subservient authorities are clarified by the organizational chart, we are remiss to remember the following truths: Those in authority are not made so because they are the best Those in subservience are not made so because they are the worst Authority is neither power, nor superiority of mind or innovation Project teams are made of real people with personalities and feelings Every single project benefit from team continuity Each truth could be its own book. But each should be inserted as part of a project's culture. Mutual respect, regular communication, and regard are necessary part of human interaction. Still, progress is better than consensus. A project's endgame is a product, not friendship. It may be difficult to "remind" other members of your authority over them. Confrontation is awkward. But "paralysis by analysis" is real. Discussions eventually need to end. Decisions need to be made. And depending on the level of the leader, they see this earlier. Conflict Most project conflict stems from ambiguous authority. Is the business, the architect, or the advocate the final say? In our need to be needed, we can promote our ideas intensely. But a project organization chart and detailed job descriptions defuse these conflicts many months before they arrive. Action items What can you do? Start with a project charter. It's essential to define success and describe the project, the goals, and the team. Don't forget a list of roles, job descriptions, and an organization chart. And, be dedicated to establishing the project culture. Not just fun and just high-quality, but respectful with a clear understanding of roles, and why you've set it up the way you have.

Apple does not care about security!

Of course, I do not really believe that. But, reading this article makes you wonder just how much Apple really does care. They're likely just saying, "Screw Windows users."

Read the article