Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Software Architecture and the single developer

Posts: 27
Google Web Toolkit Tomcat Server Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Most if not all that I read on architecture, design, etc. is oriented at programming teams. How might your approach to software architecture apply to the lone developer, or (in my case) the developer whose product(s) is almost a standalone component? In my case, I'm responsible for several thin client apps to a large, complex, legacy server backend. There are thick clients--Windows, Mac, and XWindows--and me, the web stuff (yes, we all have some input on the server, but change there comes slowly).

The thick clients are pretty tightly wound, but when folks think web, they think dynamic, flexible, customized, integrate with my pages, etc. The discussions I read and many tools/APIs start with the assumption of a team the divides up front-end, back-end, CSS, mobile, etc. All this makes for a lot of layers for one person to code and navigate. What does this book offer for someone in such a situation?
Ranch Hand
Posts: 93
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Thad,
I think being a single developer is no excuse to ignore architecture. You can have fewer layers and take up multiple roles at one.
When you do grow and decide to have multiple devs, it might be difficult to refactor architecture. So it's still good idea to have proper architecture.

sharp shooter, and author
Posts: 1913
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The book is essentially about how to introduce a minimal set of lightweight software architecture practices; including "just enough" up front design, communicating the architecture using a collection of simple sketches and ensuring that any important risks are catered for. In my view, these practices should be undertaken for software projects of every shape and size, including those with a single developer. Of course, you are a single developer today, this might change next month.

The trick, particularly if you're a single developer, is to ensure that any software architecture practices you do follow add real value. The same is true of how you decompose your codebase - there are no correct answers here, except that you need to identify the trade-offs that you're making. Lots of layers potentially provides you with some nice flexibility and agility, but the cost is added complexity. A simpler solution may work well now, but potentially at the expense of future extensibility.

In terms of some concrete advice, it sounds like you work in a large organisation. If this is the case, and these systems are mission-critical, what would happen if you left the organisation? Is there enough supplementary documentation for somebody else to pick up where you left off? Would somebody else be able to understand the structure of the code? Is the architecture that you have now "working"? Perhaps starting to map out the architecture of your system(s) using some simple diagrams (e.g. my C4 approach) will give you a starting point for answering questions about layering, etc. I hope that helps, but feel free to reply if it doesn't!
    Bookmark Topic Watch Topic
  • New Topic