Agile Zone is brought to you in partnership with:

Having worked as both a developer and an operations manager, I’ve gotten all too familiar with the ever widening gap between what developers and customers consider “done”. In order to help narrow this, I’d like to share some of my ideas and experiences concerning the software development processes with a vision towards actually releasing what customers need. Daniel is a DZone MVB and is not an employee of DZone and has posted 27 posts at DZone. You can read more from them at their website. View Full User Profile

Stabilizing Application Architectures Through Simplification

07.14.2011
| 1173 views |
  • submit to reddit
Consider the following: People are complicated and companies are run by a lot of people. A relationship between two people is complicated. Relationships between companies? Well, you see where I’m going.

Outsource a software development project requiring 10 developers, an on-site team of 3 managers and 4 developers, involving a total of 4 external companies. Surprised that the shipped product is more complicated than you originally planned? You shouldn’t be.

Complexity is in the details

We’ve all encountered this phenomenon in software projects. If it seems too easy, it’s because you’re missing something. This is why we do Planning Games – to spend an extra hour carefully thinking about these “easy” stories – picking apart the plain vanilla requirements and finding some very important open questions.

As software engineers, we tend to overdesign and overarchitect. Now, offshore the project and get ready for the fireworks. External engineers have no clue about your business, and could care even less about the project’s success. On top of this, the channels of communication are constricted. Sufficiently insulated from reality, the offshore team is free to dream of the “perfect solution”.

Creative Commons License benjamin-nagel

Perfection meets reality

In a perfect world, nothing fails. And this is exactly how those consultants engineered the architecture. No fail-over servers, no backups, and no documentation.

Pro-tip: make the consultant reboot the server at lunch time every day of their last week. Make detailed bug reports of all the failures that occur and get them fixed before the consultant takes another job!

Stability through Simplicity

You know your business and, hopefully, what your customers need. I’ve done enough “in-shoring” of projects and architectures by now, to recognize the patterns. Over-implemented security measures, unnecessary servers and lots of external ISP support.

Cutting through the baked-in complexity of a project years in the making isn’t easy. But, if you focus on the end customer value, you can start to quickly

References
Published at DZone with permission of Daniel Ackerson, 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.)

Tags: