Modern Digital Website Security: Prepare to face any form of malicious web activity and enable your sites to optimally serve your customers.
Containers Trend Report: Explore the current state of containers, containerization strategies, and modernizing architecture.
CEO at hello2morrow, Inc.
About
In 1993 I founded my first company ootec GmbH which did consulting and programming services for large German companies like Siemens and BMW. Here I worked a lot with C++ and later also with Java. I learned the hard way that neglecting software architecture can be quite painful down the road. In the late 1990 we were working on a Java static analysis platform for BMW. BMW needed a platform to ensure that Java projects would conform to their quality and architecture rules. That project was such a success that I always dreamed of making a product out of that. Well, in 2000 I got an offer for ootec from the French Valtech group which I could not refuse. So I sold my company and moved on to new shores. In 2005 I created hello2morrow together with Dietmar Menges, who played a key role in the BMW static analysis project. The goal was to make our dream come true and build a solid static analysis tool for Java and other languages. The first release of SonarJ was published in late 2005. In the meantime the product was renamed to Sonargraph and our newest family member Sonargraph-Explorer also covers C# and C/C++. In 2008 I moved to the United States to expand hello2morrow to the land of unlimited possibilities. As you can imagine that was not the best possible timing, but I am still here and loving it I still love writing code way too much which sometimes leaves not enough time for other business aspects like marketing and sales. Next to writing code I love Jazz, strategy games, hiking with my family and dogs and Red Wine, especially together with some good food. I am also working on my Jazz guitar skills, but here the progress is lacking. Damn, so many chords.
Stats
| Reputation: | 556 |
| Pageviews: | 38.7K |
| Articles: | 0 |
| Comments: | 22 |
Comments
Aug 19, 2020 · Dan Lines
We are a small team of 4 developers and use Jira in the cloud since 10 years - we still love it.
Jul 17, 2020 · Ravi Kiran Mallidi
I would add Sonargraph-Explorer (https://www.hello2morrow.com/products/sonargraph/explorer) as a very useful tool for code visualization and metrics gathering. It is not open source, but totally free.
May 03, 2019 · Jens Dietrich
Sonargraph-Explorer is now totally free and available for Java, C# and Python. It comes with very powerful and scalable dependency visualizations. It also computes metrics and analyzes cyclic dependencies.
May 03, 2019 · Jens Dietrich
Sonargraph-Explorer is now totally free and available for Java, C# and Python. It comes with very powerful and scalable dependency visualizations. It also computes metrics and analyzes cyclic dependencies.
Feb 21, 2019 · Sibanjan Das
Add Sonargraph-Explorer to the list. It is free and a great tool to analyze architecture and dependencies and find quality flaws.
Jun 28, 2018 · Mike Brown
I was assuming something like that. DZone needs some level of quality control for content.
Jun 28, 2018 · Mike Brown
I hate to say this, but this is a poor article. I was really interested to learn a bit more about Golang, but the article basically claims that Golang is cool and Java sucks. Might be true, but it should be backed up by some well researched facts.
Dec 08, 2017 · Tasos Martidis
Your article is great, I was just missing the part "How to enforce my architecture".
Dec 01, 2017 · Tasos Martidis
Software Architecture is pretty useless, when you are not able to enforce or check architectural rules. Your lovely Power Point slides soon will have no relation to the code. Here is something that fills that gap: http://blog.hello2morrow.com/2016/08/how-to-organize-your-code/
Apr 21, 2017 · Duncan Brown
A great help for code reviews is Sonargraph-Explorer (https://www.hello2morrow.com/products/sonargraph/explorer). It is free and works for Java and C#.
Feb 28, 2017 · Grzegorz Ziemoński
Now I see what you mean. But that is just a decision of the architect. In my projects the domain layer is on the bottom since more than a decade. It is just bad practice to make your business model depend on infrastructure.
Feb 27, 2017 · Grzegorz Ziemoński
What i found that in most of the monoliths I have seen the inside layer coupling is getting to a point where nobody understands the code anymore. Testing becomes a lot more difficult too, because there is nothing you can test independently. And maintaining slices/segments is not that difficult as long as you follow certain design patterns and use automated tooling to enforce the rules, you just have to teach your team how to use them. This is a one time effort that will pay off very nicely. So from my experience I can say - if you go monolith do a well structured and modular monolith.
Feb 27, 2017 · Grzegorz Ziemoński
What is the difference to a layered architecture? Same idea - lower layers must not depend on layers above them. To stay with the image, you also need to segment your onions. Otherwise you will have lots of circular dependencies between the different business objects with will definitely inhibit modularization across business functionality boundaries. See https://dzone.com/articles/how-to-organize-your-code for one approach.
Feb 14, 2017 · Grzegorz Ziemoński
I think code organization shoud be driven by business function first and then technical layering. If you only apply layering this is not enough for large systems to keep code organized. I like to think in separated business components that all have the same internal layering - a.k.a verical slices cutting through layers. https://dzone.com/articles/how-to-organize-your-code
Sep 09, 2016 · Duncan Brown
That is why it is so important to be very specific what "done" means. A software is only done when it meets is functional requirements AND quality attributes. And it would be the jo of higher level management to implement and enforce this rules. Only then people are actually rewarded for building quality software from the very beginning.
May 23, 2016 · Edmund Kirwan
Try Sonargraph-Explorer, it is free...
May 23, 2016 · Edmund Kirwan
Well, in the meantime there is a good way to avoid the big ball of mud by describing your software architecture in an enforceable way. We developed a DSL to do just that, google "Designing a DSL to describe software architecture". There also other tools out there that allow you to avoid the big ball of mud. According to Simon brown a well structured monolith is a whole lot easier to manage, understand and debug than a horde of microservices with unclear relationships.
Apr 06, 2016 · Dave Fecak
We are using a DSL to decsribe the structure of our systems. This works remarkably well.
Mar 22, 2016 · Christopher Lamb
Now you can use Sonargraph-Explorer for that. It is free. I completeky agree with you assessment about the negative effects of dependency cycles.
Mar 21, 2016 · Christopher Lamb
How exactly to you define Type Rank? I'd like to add that metric to our free tool Sonargraph-Explorer.
Mar 15, 2016 · Edmund Kirwan
Will have to add this metric to Sonargraph-Explorer. Should be easy enough
Sep 12, 2013 · Allen Coin
Great article. I came to the same conclusion. It is basically impossible to measure productivity of developers or teams in a way that is fair and balanced. All of those metrics used for this purpose have serious flaws.
But I think there is still a way to metric based performance improvements if we look at the concept of "technical debt". This concept has gained a lot of traction in the last couple of years and when I look at my own practical experience with using it I would say the results are quite promising. By measuring certain aspects of technical debt it is possible to limit or even reverse the accumulation of technical debt. That leads to better software that is easier to understand and therefore easier to maintain. At our company we are focussing on structural aspects of technical debt (broken architecture, cyclic dependencies etc.) and that has helped us tremendously. That experience is confirmed by other companies that also measure technical debt at least on a daily base.