Java Stuff and more

The early phases of an enterprise software development effort typically focuses on limiting, defining and availing the potential technical complexities that obstruct a successful outcome. After the scope and requirements are defined, the architects or leads get together and come up with possible architectural solutions (hopefully). This is generally where the risk-laden components are identified; an RMI component or use of a third-party web-service. And it is generally assumed that this components present the most complexity. Unfortunately, this is only partly true.

After ten years, and hours of conversation with other experienced software people I have come to the conclusion that what makes enterprise level software development so complex is the culture. This cultural complexity comes from all levels of the enterprise and manifests itself in all levels of granularity.

From a high-level, coarse grained perspective, compare software development at Google and at a large bank. Imagine developing software at Google for the past two years (I pick Google because their workspace and culture has received a good amount of press recently) and then making a horizontal shift to developing software for a large bank. Your world would be in turmoil to say the least; your hours, your clothes, your professional acquaintances, your attitude. Where Google’s atmosphere promotes creativity but demands challenging work hours; your bank job would probably cringe at new approaches, but you would never feel crushed by deadlines.

This is not to say that Google is better than your bank, but Google is better at developing software than your bank; they have to be. Google is fundamentally a software company; that is what they do. Your bank makes money. So right there, the culture of the bank is negatively affecting its software development effort.

To counteract this, organizations should reflect their software products. To continue with the bank example, if I work within the “Retail Banking and Branding” department as a developer, chances are I will be working for people that I am certain know nothing about what I do. Furthermore, any decision I see that seems counterproductive to me or my work will assuredly be a sign of my management’s ignorance. However, if I work in a software department, I will give my manager’s more of a benefit of the doubt concerning their competence.

Another, more finely-grained point of complexity is the developer’s role, or more importantly, perceived role in the organization. One of the strengths (although it can quickly turn to a weakness) of agile methodology is the amount of autonomy given to developers. In order to develop rapidly, much of the oversight and pre-conceived detailed design is handed off to the developer. In my estimation, this is a much better approach for two reasons. First, this responsibility allows the developer to become creative, test themselves and advance their skills much better than simply transcribing a designer’s UML diagrams. Second, those UML diagrams usually fly out the window after three hundred lines of code.

Of course, the drawback to this approach is that your newly energized developer is coding in circles, recreating the wheel, or simply failing to provide an adequate solution. These risks are very real and extremely likely even with experienced developers. By letting a developer go sit at their desk for days with a goal and an open, green field in front of them will almost always ensure that you get a very creative, elegant solution to a problem that you don’t need to solve. Even if you catch this divergence early, it is unlikely that the existing code will be deleted. Rather, at least some will remain, influencing the future design and elegance. The resulting code will be like a house built on slanted stilts.

How can this cultural complexity be overcome; how can you harness your developer’s drive to succeed and become a better developer without unleashing a bull in a china shop? Code and design reviews early and often. Have them propose their solution to other developers and see what happens. Once the early design is defensible, it will be harder to stray of course. But as you can probably imagine, this is much easier written than practiced. Again, culture plays an enormous role. These reviews can be confrontational, developer’s do not appreciate their code, design, intelligence being questioned. One way to tamp down the tension is through leadership; perhaps you show your design first. Also, be sure to moderate fairly but forcefully. Comments should be strictly constructive, but pay attention to body language as well. Another pitfall could be cliques within the team; they may seem positive during the presentation but start whispering and snickering afterwards. Finally, make sure that everyone presents their design, so everyone is on both sides of table.

I will write more about this later. If you have read this, you can probably think of dozens of ways in which the culture of a project eventually caused some form of failure or otherwise. Please share them. It seems more obvious everyday that people are what complicates enterprise-level software development to the point of failure, not technology.