On the other side, Soplets are formally structured (as opposed to JavaDoc for instance), there is no way of 'not' following the structure as defined by the annotation @interface class. This makes it easy to put in place and enforce project-wide programming guidelines.

Less code

Avoid writing (or even generating) cumbersome and hard-to-maintain boilerplate code. Instead, keep your code concise and tidy, and limit the lines of code to a minimum.

In combination with the Soplet Eclipse Plugin, a large part of the required functionality (such as getter and setter methods) are generated automatically as byte code. Secondary features of Soplets (such as the component binding) reduce and streamline your code even further.

Maintainability

80-90% of the costs that are incurred during the life cycle of a software product are actually generated after completion of the first release. Costs occur not only for rewriting or extending the code, but for understanding and interpreting the code correctly in the first place, and making the appropriate choices about where to apply the axe - not to mention testing and documentation efforts. 

There are many reasons for this high level of cost, and many ways to measure (or at least estimate) the grade of maintainability of the software. One important measurement is the grade of Semantic Convergence, meaning: as more semantically related data is spread inside and outside the code, the more expensive it is to maintain the code.

Soplet is a direct answer to this situation, by propagating the spatial and logical unity of a given concept. This approach makes sure that a value is defined only once and not duplicated across the code or elsewhere, and that semantically related values are close together at a single place.

Transparency

In principle, code is nothing more than a language where the programmer communicates instructions to the computer. But the code shouldn't communicate just to the computer, but to other players as well, in particular to all persons who need to understand how the given piece of software works, and what exactly is contained therin. These are not just your fellow programming colleagues, but the quality manager, the client and in some cases even the end user.

Soplets are well delimited blocks of code, which are easy to read and understand, even for the non-initiated reader. They describe one-to-one concrete, self-containing concepts. They are self-documenting, as the attributes are implementation and documentation at the same time.

Soplets are strong-typed by design, which makes it easy to navigate them in an IDE environment, as most of the Soplets are linked to each other, or to other parts of the code.  

And last but not least, given their formally structured nature, Soplets can be used to generate user and system documentation in the form of PDF, HTML, XML or other formats, be it during compile time or during runtime.

...and yet more good reasons:

Code centric

Soplets are the code-centric way of creating software. We believe that the fewer tools and configuration you need for a project, and the more things that can be done inside the code, the better it is. The programmer should focus on using his valuable skills and time for resolving business problems, and not for managing an overly complex development and configuration environment.

Agile Development

Soplets is particularly well suited for Agile Development, as it allows a high level of flexibility. Flexible structures, strong-typed units and a code-centric approach facilitate extensive refactoring and adapting the code to constantly changing requirements. You could also go so far as to call Soplets a way of Agile Modeling - for more insight on that aspect please look at What's wrong with MDA? for more details.