One more commit

Last week I posted an article on the future of Java build tools, which received lots of positive feedback both here on this blog and on JavaLobby. That post focused more on the differences between various build tools and advantages of one over another. This week I decided to follow up with an article, which instead will talk about something that all kinds of software have in common: the risk of feature creep (in the context of build tools).

Feature creep in action

Build scripts are very fragile pieces of software. They are treated differently than other programs that we write. The companies coding rules rarely apply to code written in XML, and refactoring or testing build scripts is something that’s hardly ever done. Because of that, it’s often easier to break the build by changing the build logic, than it is by changing application logic (the other one happens more often, but that’s because the application code is changed way more frequently).

The other problem, which is sometimes mentioned as a main headache with build scripts, is their complexity. Scripts can get thousands of LOC long, split (chaotically) over a dozen or more files. Can you imagine the pleasure of debugging those, when something starts failing?

In my opinion fighting complexity of build scripts can be done two-fold:

• by using a better build tool
• by reducing the scope of the script

Compared to regular application development, picking a build tool (Ant, Maven, Gradle, etc.) is more or less like choosing a programming language: you consider IDE support, friendliness of the syntax, sometimes performance characteristics (rarely ever done for build tools, though). There’s also your team’s qualifications, and more often than not, your companies standards (so the choice can be completely out of your hands).

On the other hand, there’s reducing scope, or managing feature creep if you will. The more your build script does, the longer and more complex it becomes. The more features you add over the time, the less maintainable it comes to be. This leads to conclusion that the smaller the scope, and the rarer the changes to it are, the better.

Build scripts can range from the most ascetic, which only build and package the application, to the most byzantine, which will download the applications sources, compile, package, test, generate reports, generate and upload documentation, install all prerequisites on the build and deployment machines and finally deploy and run the built application. As the CI servers grow in popularity, it is possible to do more and more with appropriate plugins instead of home-made build scripts, but while they help reducing the scope a little, there’s still a lot of stuff that they can not do.

It seems reasonable to ask: what should a build script actually do then? Should it stick to the very basics? Does it make sense to have A-Z build scripts which can do everything with a single command? I wish I could give you an answer to those questions right here and right now, but I can’t. The feature list of a build script is in my opinion heavily dependent on the application itself, and the technologies in use.

One thing that could possibly help fighting the feature creep, is defining what the build script should do in advance. What reports are relevant to this project? Should the script be able to deploy the application, and if yes, which deployment scenarios should it support? Should it just generate, or also upload the build artifacts, like .jar files or documentation somewhere? What kind of notifications should be implemented, and so on. With this, a build script once created, should be left relatively unchanged. However, this seems rather restrictive, and definitely not “agile” at all.

The more agile approach could be by mimicking what has been done in the Grails framework, which has a very friendly integrated build system (based on Gant), which can be easily extended. As Grails is very keen on “convention-over-configuration”, the commands reside in appropriately named files, thus helping you find the code you’re interested in easier. The separation is cleaner, and adding your own command is unobtrusive and straightforward. The problem here is mostly time, because rolling a build system like that on your own is definitely harder than using something “out of the box”.

So the best practices I can name are: do as little as possible, but as much as necessary and keep your build code in bite-size, easily identifiable pieces - not one 10k LOC build file, but maybe dozens of small files named by convention. Not much, huh? That’s why I’m counting on you, to comment on this post, and share your opinions.

Can you share any good/bad practices for build scripts? Do CI servers make your life easier, and if yes, how so, and which one do you use? How often does your build script change? Do you have any particular way of organizing your build scripts?

Waiting for you feedback,

Adam

PS. Thanks to Pete Johnson for inspiring me to write this:)

My last post: The future of Java build tools has been featured on JavaLobby. Sweeeeeet :)

UPDATE: A follow up to this post has been posted here.

With a short post on dzone Adam Bien revived an old flame-war: should we use Ant or Maven as our build tool. The post itself seems a little biased on the maven side,  but not much. The only really questionable sentence is:

The real strength of Maven is its dependency management. (…) Ant doesn’t have such capabilities out-of-the-box (except via Ivy) and it will take a considerable amount of work to emulate Maven’s dependency management with Ant.

Although it’s certainly true that Ant does not have dependency management built in, it’s fairly easy to incorporate Ivy into your build.xml, so the “considerable amount of work” part is in my opinion rather misleading. UPDATE: There are of course other tools, which can be integrated with Ant for dependency management: Maven Ant tasks and Savant (thanks to Brennan Spies and Brian Pontarelli for pointing that out).

However, given a choice “Ant or Maven”, I would most likely choose the former. I can see why so many people today use Maven as their primary build tool. It is pretty cool to have this drop-in build script, that with only a few lines of configuration will give you so many possibilities: dependency management, built in tasks for compiling and packaging applications, integration with Jetty, neat project web site, integration with cobertura, pmd or findbugs. In a situation, where one starts a new project, which is fairly typical (say a web application using Spring & Hibernate) this seems like a very good choice. I will say even more: for a project like that, this is probably a good choice.

No one really wants to write build scripts. This is the kind of code that does not have any real business value. Unfortunately that last statement holds only if the build script actually works, otherwise it has business value: a negative one. I feel that a build system like Maven is really great until you start encountering problems with it. Maybe your project just does not fit so very well in the convention. Maybe plugins you want to use conflict with each other. There’s lots of points of failure in a build system like Maven - and oftentimes it’s very hard to track the source of them and fix them.

The choice of Ant over Maven is not a very clear one. It truly is a chore to be forced to write all this build code by hand. But when the things go south, the build script is just another piece of code you’ve written. If you did it right, you should be able to find your way around that code, and fix it. No magic here.

OK, I’ve written enough to spill some oil to the flame-war fire. Now to the point of this article: are Maven and Ant our only choices? Is there really nothing better than that?

I claim there is. Over the last couple of years we’ve seen many such projects spring up to life. Those tools no longer use XML to define build logic, but real programming languages like Groovy, Ruby or Python(? - I thought I’ve seen an announcement somewhere for build tool in Python, but can’t find it now). They often allow dependency management (through Ivy or Maven) or Build By Convention. Some of those tools are:

• GRADLE
• Gant
• Kundo
• Raven
• Buildr
• UPDATE: Schmant (thanks to Erik Tjernlund)
• UPDATE2: Lancet (thanks to Vassil Dichev)

My favorite build tool was Gant, up until the first release of Gradle was announced a couple of months ago. Gant is basically a Groovy way of invoking Ant tasks, which by itself gives you a lot compared to a good old build.xml. By using a real programming language instead of XML, some tasks which could become tedious in XML, are very easy: extracting common code into methods, loops, conditional logic (yes, I know about ant-contrib and use it whenever I have to use Ant, but trust me, it’s not the same). The fact is, that XML is not a programming language and it should not be used as one. Build scripts in languages like Groovy or Ruby are more concise and easier to read. There’s less clutter, boilerplate code, and your build script can be structured better.

In my opinion, the future of build automation in Java environments is Gradle, or at the very least some other tool, which will exhibit similar properties. Gradle is the kind of drop-in build script that I like: for simple, standard projects it allows you to use itself with just a few lines of configuration. It even allows transitive dependency management without using Maven or Ivy repositories. You know, how when you first learn about this “dependency management” thing, you wrote down your dependencies in ivy.xml or pom.xml and it took forever while “Maven downloaded the Internet”? How eventually you had to install a private repository just to store those dependencies which could not be found in the Maven repositories? How you had to fix pom.xml files, because some of the artifacts didn’t declare all their dependencies? Well, now you can have DM without all those problems. Just store the required libs in the SVN repository, and switch to “real” DM when needed.

On the other hand, for bigger projects, among many other features Gradle has first-class support for multi-project builds (for example, you can specify project dependencies, and when you build one of the sub-projects, all it’s dependencies will be built too). There’s plenty of other features and cool “magic tricks” you can do with Gradle. Check out the User’s Guide on the project web site. It’s about 100 pages long, and provides plenty of information. I mean it: you owe it to yourself to give up an hour of your time and read that manual to see how much better your life would be if you used Gradle :o)

That being said, I have to admit: Gradle might not be suitable for “production use” yet. The project is still fresh out of the oven - it’s less than a year old. It’s impressive how much Hans Dockter and other commiters managed to achieve in that time, though. The documentation is IMHO very good - short enough and informative. If you are looking for a replacement for Ant - Gradle is the thing for you. If you’re looking to replace Maven, you might want to wait a couple of months, since Gradle does not have support for many of the features Maven users rely on, like the project web site or generating project files for main IDEs. There’s also currently no IDE support for Gradle.

To summ up: while there might not be a “one size fits all” solution to build automation, new tools being developed seem to come close. By allowing both build by convention, and combining it with do-it-yourself-if-you-like approach Gradle has a shot at attracting both Ant and Maven fans. In the future I expect build scripts to be written in programming languages like Groovy or Ruby, and Gradle is likely to gain a significant market share.

After a long period of inactivity, this blog is coming back to life and there’s gonna be some changes! Some of those you may observe already - a new theme and a new domain address. The new domain is kind of problematic - as I don’t own psyho.pl any more, the links to this site are broken (at lest for the time being). This unfortunately also includes links from dzone. The RSS feed is still OK - thank’s to FeedBurner.

I’m thinking about changing the title (as the current title is a result of about 15 minutes of consideration), but first I want to make sure that I’ve come up with a good one. Email me, if you have any suggestions about that (or anything else for that matter :). Oh, and I definitely have to update my about page too…

The post topics will stay similar to the ones I’ve put up in the past. Hopefully from now on I’ll post at least semi-regularly. I will try to write more, but shorter posts - wtith code snippets, etc.

Cheers!

Adam

Change by Banksy

PS. If you like the grafitti - it’s a piece by a famous artist called Banksy. Check out more at:

The World According to Banksy

I’ve recently used a site that allows querying WHOIS servers and got annoyed by the requirement of every time typing in the captcha key, so I thought to myself: “Wouldn’t it be groovy to write a Groovy WHOIS client?”. Well, it is :) So without any further ado, I’m presenting that finished script to you.

def domain = args.length > 0
? args[0] : 'google.com'
def server = args.length > 1
? args[1] : 'whois.geektools.com'
new Socket(server, 43).withStreams {input, output ->
output << "${domain}\r\n"
println input.text
}

As you can see, the script uses Groovy extensions to JDK classes, such as Socket (method withStreams(Closure)), InputStream (getText()) and OutputStream(leftShift(Object)). Neat, huh?

Keep on coding!

Psyho

There’s a new contest on GWT Site, and it’s the biggest one yet. There’s 16 prizes to be won, including EXT GWT and GWT Designer licences and copies of three different books on GWT. To enter, you just need to subscribe to the sites email newsletter and/or add a comment to the blog post.

Good luck!

Adam

First of all, I would like to apologize everybody for not writing for the last two months or so. I’ve been so swamped with work, that I didn’t even have time to read all my feeds in Google Reader - not even speaking of writing something here. Hopefully now, I’ll find a little more time for that. So without any further ado, let’s get to the topic of today’s post.

Lately, I’ve been doing some work with Grails on a custom back-office application for a medium sized company here in Krakow. The application isn’t very complex - mostly CRUD operations, nothing really complicated. We chose Grails as our Web Framework, because we think it’s ideally suited for this type of stuff (talk about Rapid Application Development…). At some point we decided to add some Dynamic HTML/AJAX features - dynamic grids, that load data from the server without refreshing the page, some animation here and there, some dynamic menus, dialogs etc.

My first JS library (if you can call it that) of choice has been GWT. For some time I’ve played with Ext GWT (I know I bashed it before on this bog, but we didn’t really mind the application going GPL here). What I’ve found out, is that GWT isn’t especially well suited as as sprinkle-on-top solution for “ajaxifying” your site. Don’t get me wrong - I love GWT, it has no match for creating a fat-client JS application: the Swing like UI programming, static typing, all the Java IDE goodness at your disposal, and to top that performance and cross-browser compatibility. Even if I had to program every widget by myself, I’d choose it any day over any other solution. The problems start when you just want to add a little of the AJAX magic here and there in an existing application. In such case, more often than inserting some widget into a div on a HTML page, you want to manipulate the DOM tree. Sometimes you don’t want to have the code that decides what to insert where placed in the GWT module - maybe you want to have some function like insertGridHere() with parameters indicating stuff like URL to take the data from, title of the grid, etc. that could be placed anywhere in the HTML code of your page.

GWT hasn’t been designed with stuff like that in mind - the DOM manipulation API has been only available since version 1.5 RC2, and it only provides some basic DOM manipulation methods - nothing like JQuery, for example. Speaking of devil - a couple of months back Timepedia announced GQuery - a GWT port of JQuery library. I have high hopes for this library, although without commercial support, or even half-decent documentation I don’t think it will be able to take off. I would really like to see people developing plugins for GQuery, like they do for JQuery. You see - the strength of JQuery doesn’t lie as much in it’s excellent support for DOM manipulation, special effects etc. it’s in the plethora of plugins available for it. Want a AJAX-enabled grid control? - there’s like 5 of them. Modal windows, tooltips, accordions? Everything you could imagine is there, and often there’s more than one option to choose from.

Even though I started implementing the dynamic features of my application in GWT, I’ve switched to JQuery along the way. It has it’s disadvantages - I’m never sure if the code I write will run in every browser we want to support (big, big, big disadvantage), the code is not obfuscated in any way (although this can be prevented by using a JS minifier). I also find that I much prefer to organize my code into many little .js files (for better readability), which in turn makes my application initialize slower (I need to use .js packer). The advantages however include having the aforementioned plethora of plugins available at my disposal, each of which is usually designed to be used separately (unlike the usually tightly integrated libraries like Ext GWT). Most of the time the JS code is a lot less verbose than the corresponding Java code I’d have to write to implement the same functionality.

Although for now my first choice for “sprinkle-on-top” AJAX applications is JQuery, I’d really like to go back to GWT. The lack of cross-browser compatibility of the code I write in JS is really annoying. To have the abilities of JQuery, combined with even a friction the number of plugins available for it, and the features of GWT like Java programming language (code organization, code documentation, automatic refactoring, code completition etc.), highly minified and performant code it produces and many other advantages it has, would be a dream come true.

In my opinion GQuery should be adopted by the core GWT team and incorporated into the framework as an addition to the DOM manipulation features it already has. This would probably result a number of plugins springing up to life, and better support for the library. It would also greatly increase the GWT’s abilities to enhance existing web applications. Other than that I’d like to see some kind of ability to define JS libraries in GWT with a public interface, that could be called directly from JavaScript on a HTML page. An interface like that could be probably already defined with a mix of pure JavaScript and JSNI, but why resolve to dirty hacks, when we could have this use-case covered in the core library?

And how about you? Are you using GWT to enhance existing applications? Should GWT even be used for that? What kind of features would you like to see added to the core library, to help you with that task?

A couple of days ago, Sanjiv Jivan announced the names of the new members of the Gwt-Ext project. This comes after his decision to step down as a project lead, which was triggered by the Ext JS license change (and the discussion that followed). I don’t really want to summarize the argument between Sanjiv and Jack Slockum (Ext JS main contributor). Below are the links to the relevant blog posts:

1. Gwt-Ext user catplusplus writes in a forum topic about a fork of Ext JS called OpenEXT Jack Slockum responds to that post in that topic.
2. Sanjiv Jivan responds to Slockum on his blog
3. Slockum posts his thoughts on the license change, and answers to (what he calls) personal attacks. This post is located here, but if you want to read the original (unedited) version, you can download it here. The original is significantly longer and addresses Sanjiv Jivan’s arguments.
4. A few days later Sanjiv posts an update on the future direction of Gwt-Ext, in which he announces his decision to step down as a project lead.

As of now, the Gwt-Ext project supports only the LGPL(ish) Ext JS 2.0.2, and not the GPL 2.1 version. I strongly support that decision, but cannot help but to wonder if the Gwt-Ext project still has a future. Gwt-Ext is a GWT wrapper for Ext JS, and as such should do it’s best to support the current version of the wrapped library. On the other hand, a huge selling point for it was that it was free (as in free beer), and going in the other direction, would mean loosing that advantage. How will the new contributors deal with adding new features to Gwt-Ext? As long as they were wrapping Ext JS, they only had to wait for the Ext team to add some feature and wrap it, now they will have to start thinking about adding new stuff by themselves. Won’t that be too much of a burden? I really admire Sanjiv Jivan’s work, so it’s not easy for me to say that I don’t really see a future ahead of his project. It’s by no means his fault, and I really hope I’m wrong. There is just no right direction in which the Gwt-Ext project can turn, and any decision made by the team will probably be a wrong one. This pretty much signals that Gwt-Ext will soon face extinction.

This brings me to the main point, which I meant to discuss in this post. How much this Ext JS license changing business affects the GWT library landscape? You may remember Gwt Site having a contest for the most popular GWT library, here you can find the results of that contest, and below you can read the Top 5 GWT 3rd part libraries as of January 14th 2008:

1. MyGWT
2. GWT-Ext
3. GWT-SL
4. Gwittir
5. Hibernate4gwt

As you can see, the two most popular of those libraries are Ext Js based. MyGWT, now an Ext product rebranded to Ext GWT (for the sake of clarity I’ll refrain here from using that name in favor of MyGWT), is a library that directly competes with Gwt-Ext, but written completely in Java. The earlier versions of MyGwt used only Ext JS images, version 1.0 uses also it’s CSS stylesheets. With Darrell Meyer joining the Ext team, the license/business model change also affected MyGWT (despite Darrell announcing that MyGWT will stay LGPL in 1.0 earlier on MyGWT forums).

Today of the two most popular GWT libraries, one changed it’s licence, and is no longer freeware, and the other one’s fate is still uncertain. I don’t have a problem with paying for MyGwt, mind you. Actually, if Darrell announced the change a couple of months back, I probably wouldn’t complain at all. It’s pretty common to pay license fees for widget libraries after all. The problem for me is that the licensing terms seem no longer to be in Darrell’s hands, but Jack Slockum’s and I just plainly don’t trust that guy at all.s For all I know tomorrow MyGwt might be AGPL/Commercial and God knows how the commercial licence terms will change in future. Charges per deployment / user/ CPU - everything seems possible if Jack decides that he’s still making not enough money out of his library.

I have mentioned before the OpenEXT project, which is going to be a set of patches that you apply onto the Ext 2.0.2, this way conforming to it’s license and being effectively a fork of Ext JS. I think it would be great to see someone doing something simmilar with MyGwt. MyGwt was licensed under pure LGPL license, with the exception of the so called “assets” (css and image files). Maybe it would be possible to create a real fork of this project given that it’s only dependency on Ext JS lies in the assets? I don’t feel up to the task, but I still hope that someone will eventually step up:)

For me, both MyGWT and Gwt-Ext are now practically useless. It’s a real shame since these are really wonderful tools for creating slick-looking back-office applications. However I cannot invest my time (and therefore money) in creating software using a tool, which might stagnate or become no longer supported (Gwt-Ext), and I don’t want to give money to an unethical and greedy company owned by Jack Slockum. So what can be used instead of those two libraries? I’ll propably check out IT Mill Toolkit which is licensed under Apache 2.0 licence, or maybe just stick with plain old GWT widgets - the new showcase application looks pretty nice, and there will be three styles to choose from. Anyway I think that with recent developments, a place has opened in the market for a new Gwt-Ext/MyGwt-like library. Hopefully it will emerge soon.

When Ext license change topic was still hot, one of the bloggers wrote a nice post titled “Ext Discovers Step 2 of the Slashdot Business Model?“. To thank you for reading this pretty long post, I’ve decided to add an episode clip from South Park, which I thought about immediately after reading his post. Unluckily for us, Ext JS team has discovered what the step 2 is…

Cheers!

Psyho

Recently I needed to make a server application run as an Unix daemon and be able to start, stop and restart it on demand. The application I’m talking about didn’t have any startup/shutdown utilities analogous to for example Tomcat. It run as a script, without even detaching from the console. At first I figured I’ll have to write a utility application that would start the process, store it’s PID in some file and somehow “daemonize” the forked process. So as always before doing anything, I decided to check if anyone hasn’t done that before me. I wasn’t really surprised when a quick Google search allowed me to find a utility written by someone just for that and even more. The application is called start-stop-daemon and should be installed by default on almost any Linux (well, it certainly was on my Ubuntu 7.10).

Below is a quick tutorial on how to start any server application as a Unix daemon on system startup. It was tested on Ubuntu Linux version 7.10 (Gutsy Gibbon), but it should work on most Linux distributions, and certainly on those which are Debian based.

Let’s assume that the application we want to run is /path/to/script/app.sh

First, we need to create a script in /etc/init.d/ Let us name the file /etc/init.d/app

The file contents would look something like this:

#!/bin/sh

PATH=/bin:/usr/bin:/sbin:/usr/sbin

case "$1" in
start)
echo "Starting application"
start-stop-daemon -d /path/to/script -c username --start -b -m -p /path/to/pid/app.pid --exec /path/to/script/app.sh
echo "Started."
;;
stop)
echo "Stopping Application"
start-stop-daemon -d /path/to/script --stop -p /path/to/pid/app.pid
rm -f /path/to/pid/app.pid
echo "Stopped."
;;
restart)
sh $0 stop
sh $0 start
;;
*)
echo "Usage: app {start|stop|restart}"
exit 1
;;
esac

exit 0

This is a pretty standard service startup/shutdown file. The most interesting part of this script is the use of the start-stop-daemon application. This line:

start-stop-daemon -d /path/to/script -c username --start -b -m -p /path/to/pid/app.pid --exec /path/to/script/app.sh


starts the process as a daemon. The -b option makes the process run in background, the -m option is used to create a PID file, -p specifies where the PID file is located (the directory where the file is located must already exist, as it won’t be created automatically), -d specifies the current directory that will be seen by the script, -c changes the process owner. The start-stop-daemon application will check for PID file when starting, and won’t start the script if process with this PID exists. If the script for some reason fails to start, or encounters an error, the PID file won’t be deleted, so keep that in mind. This technique is certainly not for general-purpose usage - it should be used only when you don’t have any other way to properly startup your server (or maybe if you are just looking for a quick-and-dirty solution).

I figure that the line that stops the daemon does not need more explanations. Just note that the PID file is deleted manually after stopping the service - start-stop-daemon won’t do that for you.

Now we just need to make the application automatically start at system startup:

sudo update-rc.d app defaults


You can start/stop/restart the server the same way you would do it with for example Apache:

sudo /etc/init.d/app (start|stop|restart)

Hope you’ll find this trick helpful:)

Psyho

I’ve recently watched a great presentation by Venkat Subramaniam titled “Pragmatic factors for Agile Success“. It’s about one and a half hours long, but if you’re doing agile project management in your company, I believe you should definitely watch it. Venkat talks about some good and bad practices, and mostly deals with communication issues. The presentation is cleverly organized into parts, each of which having two sides of it’s own - one beginning with a little devil saying some stuff (the bad practice) and the other one with a little angel saying how the things should work.

The part of the presentation, which in my opinion got the most attention from the audience (and myself), was the part where Venkat talked about the idea to criticize ideas and not people and dealing with communication between team members in general. I believe that this part is highly relevant to lots of people, because the every day communication is possibly the hardest thing to get right in any team. I strongly support the ideas of egoless programming and making design (or for that matter any other kind) decisions based solely on the solutions merits and drawbacks. The latter is the idea that I’d like discuss a little bit more in this post.

I think that although picking some solution based solely on it’s advantages and disadvantages is the only logical thing that comes to mind, I disagree that it is possible to just “let go” of the idea’s ownership. Of course you should go ahead anyway and try not to think about the solution in terms of “my idea” or “someone else’s idea”, the problem is that no matter how hard you try there is just no possibility of really doing that. Sure, you can release the idea, no longer considering “yours”, but if you have already put a substantial amount of thought into it, it’s become a product of your knowledge, experience, your character and beliefs. Your idea is yours not because you consider it yours or not, it’s yours because you’ve made your mark on it.

Hardly ever do you encounter a problem which solutions can be objectively evaluated to pick the best one. Most of the decisions we make are made totally subjectively. Of course in software design the subjectivity level is lower than in for example making business decisions, but it’s still there. From my experience, the area in software design that raises the most controversy is user interface design. The reason for that is that in user interface design you often base your opinions on your own preference. Something that is unintuitive for one person may be perfectly intuitive for another. Other design decisions can be evaluated a little better - something either handles concurrency, or it doesn’t, it handles all the functional and non-functional requirement’s or it doesn’t. However, even if you created a list of facts about some design, which are objectively true, people still can differ about how important those features are, as advantages or disadvantages. What I’m saying is, even when everybody in the team is perfect and letting go of the idea ownership - it’s still pretty hard to arrive at a conclusive decision without someone coming and saying: “OK, I’ve heard all your arguments - let’s do it this way” and ending the discussion. It’s not anybody’s fault - it’s just human nature.

In Agile the communication between the team members is of utmost importance. It’s really hard to succeed if you can’t talk with your team, so we should all try our best and learn communication skills. But if you have a colleague, that disagrees with your opinions and criticizes your designs, don’t think that you’ll change this by just changing the way you speak to that person. You have to understand that the differences between you will still be there, and you’ll still disagree with each other, but that’s the way it should be. The key is to seek those differences, because you might learn from them, and when you still disagree at the end of the day - just learn to let go, sometimes the other persons idea is different, but just as good.

Psyho