Feature

Digg This!

Page 2 of 2   « previous page

• Chasing and groking the latest software methodology/technology (e.g., JPA, PMP, Spring JMS, Ruby, AJAX, etc.) making them more marketable (and better positioned to pay their bills!)
• Creating software products and libraries (open source included) that can be reused (the DRY principle) by other technologists
• Building and deploying software projects that are successfully used by their business customers.

As we mature, we tend to stake more and more effort in this third item for two main reasons: 1) because that's what we're paid to do and 2) we have a duty to our business customers to "see it through." The evo-cycle and the lack of stamina to fight it is what typically work against this.

The Evo-cycle
The evolutionary cycle of a software project generally involves discrete stages. And it's important to note that these stages can occur multiple times (and not just because of an iterative approach) and brutally transition without any downtime (often times the biggest test of our personal and professional stamina). The Evo-cycle transcends methodology and iterations, but can be contained within iterations. What is depicted here is a general ordering; specific ordering can vary/overlap.
1)  Planning
An implied stage of all software approaches, planning involves considerations of money, resources, prioritizations, and scheduling. Failure here is not uncommon, although we can't directly attribute that to a lack of stamina (but other words come to mind).

2)  Starting Over
The evo-cycle usually involves starting over at some point. Either it's a redo of an already attempted redesign or a redo of a chosen technology or the prime contractor was let go because the customer was uncomfortable with the results. Doing things over again takes a toll on people.

3)  Requirements
This is a traditional stage that involves sifting though customer needs and wishes, often times resulting in an ever apparent need for Business Process Management (BPM) to affect a more cost-efficient customer.

4)  Design
In another traditional stage, design is focused on the scoped items for the planned iteration/release. This involves professional collaboration, white boarding (in some shops if you stand still long enough they'll attach a white board to you), and formal artifact creation in the chosen tool. Typically during design resources are fresh, however in subsequent iterations the quality of the design may degrade because of a failure in oversight or general overconfidence.

5)  Implementation
We all know this one, the traditional "rubber meets the road" stage. This is where software developers (including specialized consultants) focus on the intense development of scoped (and hopefully already designed at a high level) requirements. This stage takes a tremendous amount of focus and, at times, overtime hours (sometimes paid, sometimes not). The amount of effort and teamwork to reach the end of this stage is usually worth a celebratory lunch, formal recognition, or at least a "pat on the back." Reality often means no recognition because in the grand scheme of things, the hard work is yet to come. (How can you say still to come? Didn't I just stress out getting these crazy requirements implemented?)

6)  In-fighting
This happens with all human interaction,. In stressful situations in-fighting happens in varying degrees (depending on the team's professionalism). Sometimes it's employees versus consultants. Sometimes it's developers against management. Sometimes it's consultants versus consultants. The point is that when this happens and is not managed or arbitrated, it weakens the team and the stamina of those involved.

7)  System Testing
Metaphorically speaking, this traditional stage is a battle (and requires that kind of mindset). The reality is an unanticipated amount of system defects that must be resolved. The testing team works extremely hard to exercise all system paths. Just coming off the tiring implementation stage, the development team frantically tries to fix problem areas (especially their own). Problem areas range from easy to so complex that they have to be completely refactored. Probing questions of system stability and performance begin to surface. Developers start growing weary.

8)  Stability
Here it is. The first big impact of the evo-cycle. All the professionals involved have exerted tremendous efforts to get to this point. But the entire project is at risk. The system isn't stable and grows unusable. How can so much effort still result in an at-risk project? People feel they need a vacation (and it's not the best time for one). Many times this stage is quickly resolved internally by using system monitoring tools (e.g., JProbe detecting a memory leak or dangerous non-thread safe code). Other times outside consultants are brought in to assist. Depending on the visibility of the project, the stress this brings is unmeasurable. I was even on a project where legacy stability problems were documented in the Washington Post. That's stress. Got stamina?

9)  Politics
Politics plays a nasty role, another stage unique to the evo-cycle. It's inevitable though. Customers reorganize because of a new CIO. Developers blame each other. Consultants cover their tail and try to get a bigger piece of the pie. More in-fighting ensues. People lose their commitment to the project.

10)  Performance
To get to this stage, a lot's gone on. The system's been built, refactored, tested, and stabilized. Multiple times. However, now it's not performant (does it meet the performance requirements of the customer) with a customer's message/usage load. It's too slow. People start blaming everything. Hardware. Implementation. Architecture. Java. You name it. To address the performance problems of a system requires a specialized toolset and mindset. By this time, many original consultants have jumped to the next great technology in preparation for their next gig. Employees are tired of working unpaid overtime. The team isn't the same as when the evo-cycle started. Software professionals must rise to the challenge to scale the system. Some of my proudest moments are when a system is stabilized and performant. It's even more satisfying when there are still folks (like me) on the team who've made it this far without dropping off.

11)  Out-fighting
Another item that affects our mental state is when other organizations "pick fights" with a weary group of software craftsmen. This can take the form of an internal standards body, external consulting organization, or audit-natured groups. Extreme cases can bog a project down for months on end. As much as it can sap stamina, passage through this stage often increases team camaraderie.

12)  Funding
Funding issues can swirl around a project for its entirety or doom a project that's under-planned. More attrition occurs as consultants leave because of the uncertainty. This is one issue that most developers have no control over, but it occupies their minds.

13)  Natural Attrition
People leave companies, change projects, or just get bored. It happens. Management attempts to plan for this. But sometimes it's management that leaves. This can cause discontinuity. However, I've seen this have positive results when a bad apple leaves or a new person fresh with stamina and ideas comes on board.

14)  Final Installation
By the time a system is deployed, many people have matrixed to other releases or projects. They'll need to be pulled back (if still accessible) to support the final stretch of deployment. If the system goes to deployment quickly after system testing then it brings with it a support team of tired humans.

15)  Reality
Reality is the evo-cycle's last pass at breaking the back of the organization and software professionals. The system is finally in production. The client is starting to use it (and, if the process was intelligent and agile enough, the system has already been completely indoctrinated and acceptance-tested by the customer). Something isn't right though. The benefits aren't quite as expected. The requirements load was understated. Key personnel sour on the new system. Are you kidding me? The team must once again rally to address any and all of these issues.

16)  Warranty
Software is a product. Like all products, it should come with a warranty. In software that warranty is a support team of system operators, system administrators, and software engineers. They must maintain the overall health of the system, triage production issues, and coordinate point release updates to the system for any production defects that have been found. Initially, this stage takes a toll on the folks involved. Pagers are handed out. Critical issues are immediately brought to high-profile stakeholders (sometimes even a U.S. Congressman!).

Summary
Are you exhausted just reading about the evo-cycle? Keeping a heightened awareness of the evo-cycle and knowing its debilitating affect on our collective stamina will better equip a software shop and professional to stay in the game mentally and "see it through." To do software the right way is very hard and complex, especially in large enterprise endeavors. Besides the well-known items such as resources, experience, professionalism, and expertise, both personal and collective stamina plays a vital role in software success. It's my hope that raising awareness of the software evo-cycle can help us all succeed in our respective engagements. Expect these stages, mentally prepare for them, and do all that you can to sustain your own stamina.

Page 2 of 2   « previous page