Published Friday, 15. October 2010, 20:22, Danish time.

My story about what’s in the “CodeSoul” name and “the rare sense of code with soul” is now online. You can reach it by clicking the link in the hello there box in the upper right corner – or by clicking here.

Published Thursday, 14. October 2010, 00:01, Danish time.

There is a certain “misfit” that I have heard about from many good devs. Lots of potential productivity and quality results that are arguably not being harvested in the majority of big companies out there.

There are certain “laws of nature” that rules in this field. I will try to describe some of them here.

I think that a lot of it has to do with how developers are managed by managers.

The problem is that you only unleash a fraction of the potential benefit you can get from employing a clever developer, if you only see him/her as a sheep you have to herd – as a naïve soul that has to be lead. Modern management culture that practices lean and agile processes and work with their developers – instead of trying to lead them. But “modern management” of that quality is rarely found in the average enterprise company.

Development talent is a very different talent than management talent. Organizing systems, data and code are complex tasks, just as organizing company processes and departments and managing strategies and people. Developers handle very complex technical challenges and team dynamics. Likewise, managers need to handle other aspects in parallel, like marketing strategies and legal affairs.

I will argue that in many organizations, the average developer is at least as intelligent as the average manager.

But how do you work with nerds?

Well, the first thing you do is to cooperate. Work with your developers, in order to get the synergy going and benefit the most.

Many managers turn their back on skills and knowledge

Developers and managers live in different universes, so you have to bridge them somehow and – as always – communication is the best mean for that. And – again as always – communication is damn hard. In this case, it seems to be particularly difficult. One main limiting factor is management vanity, if I’m not mistaken: it’s apparently hard for many managers to admit limited knowledge. But it’s really not the manager’s role to know everything anymore. Maybe it was like that in a distant past – even though I really doubt that that concept ever really worked in the IT industry.

Many managers became managers because they wanted to lead other people and wanted to be in control. Many went straight into a theoretical management education. Often this isn’t a good thing if you have to cooperate with your employees rather than to lead them. Some will rather pay expensive management advisors to analyze their business, than engage with their employees in order to surface the steps the company needs to take to go forward. More often than not, there is already plenty of knowledge to harvest inside the company.

Often managers also sold themselves to the company for a high price, which leads to high expectations from above, which again leads to pressure, which again makes people try to show off by coming up with monstrous master plans without first having learned sufficiently about the business and the involved technical domains first. This pattern has been repeated over and over.

Now, I know that I am being a bit tough here – and of course there are also a great deal of great managers out there. But I definitely think that there is a trend here.

I’m also not saying that developers always communicate perfectly, nor that they aren’t partly responsible of failing communication, whenever that happens. That’s not my point. My point is that many managers become responsible for poor results, because they often don’t activate the good skills in their organizations. Managers must produce through their employees. So they must ensure that employees work optimally.

Then there is the money aspect...

You could say that all this ultimately is about what you get for your money. IT projects usually become very expensive when the organization doesn’t work on the right things…

The innate geek pride and enthusiasm

There is a close relationship between skills and enthusiasm. If you love what you do and take great pride in your work, you usually get pretty good at it.

This is especially prevalent for software developers – most developers loves to be good at their thing. And for a software developer, delivering a good job usually includes delivering something that makes sense for their users and customers – something that’s stable, robust and fast.

Delivering a good software job is usually well aligned with what’s make sense business wise.

This kind of care for what you do is present in most developers I have met. You can just ask them about their best projects, and you will see a person that lights up in enthusiasm. This is kind of unusual when you compare to lots of other professions; I guess that this profession somehow attracts people with this mindset – or maybe you just don’t keep on doing software if you’re not this kind of breed.

Sadly, you only see pride and enthusiasm in action all too rarely in the typical project work in the typical enterprise. And to me that’s just lots of wasted potential…

I don’t think though, that it’s too hard to activate the geekiness in most cases. And this is quite paradoxical considering the difference that engaged employees make to any business.

Surface the business challenges in order to engage

Posing challenges to developers and being transparent about business challenges and the competitors’ moves is often enough to activate the synergy. A company with a closely coupled business unit and development department will often do magic and also usually moves forward all by itself. By “closely coupled” I mean that developers should talk to business people directly – not through several layers of indirection, like through managers that talk to other managers or company councils that maintain written lists and distribute documents between the two parties. You need the direct contact in order to make the challenge real.

This setup however “reduces” the manager’s role to be the one that pushes gently in the right directions when changes are needed. This will usually be a simple task involving only to explain the new challenges to the involved people.

What will separate the good managers from the bad, will be how they stay on top of things and how, when and why they start pushing.

The devs will then take great pride in delivering the magic to make things happen business wise. I bet you they will! Trust me!

I’m more concerned that this “reduced” role doesn’t really satisfy the manager involved… (and if this happens, I think that the only realistic solution for the developer is to replace their manager…)

Published Friday, 1. October 2010, 00:53, Danish time.

Over time there has been a lot of ranting and quarrels on the net about ASP.NET WebForm’s “name mangling” – which is WebForm’s computed ID attributes on HTML elements generated by server side WebControls. Just try to search Google for “ASP.NET” + “name mangling”. The sum of web designer work hours spend worldwide on fighting with this in ASP.NET’s life time must be astronomical.

I have read a lot of these discussions and it puzzles me that I never found a good description of the root cause in any of these discussions on the net.

It's really a basic and unsolvable conflict between object oriented web development and precisely targeted CSS styling.

The problem is of course not unique to ASP.NET WebForms; it applies to all component based page frameworks.

Let’s go through it.

The web developer side of the problem

When you are developing a web page component and deliver it “to the world”, you never know where, how often, and how your component is used. It follows from object oriented thinking (OO) that a class doesn’t know about its container.

If somebody decides to use multiple instances of your component in the same page, and they all render the same HTML element ID, this would violate W3C standards. HTML element IDs must be unique in an HTML page.

In WebForms up until .NET version 3.5 SP1, Microsoft solved this problem by automatically computing the IDs rendered. On a WebForm, controls live inside other controls and the rendered HTML IDs will then basically reflect the tree structure that the controls form. That’s why you see IDs like “MainForm_SideBar_SearchButton”. (In this case, the SearchButton control lives inside a control named “Sidebar”, which again lives inside a control named  “MainForm”.)

If somebody then moves the SearchButton control out of the Sidebar, it will get a new ID. Not so nice if you depend on the IDs – which is exactly what web designers tend to.

The web designer side of the problem

Web designers like element IDs.

When you write CSS, the IDs have the highest priority when the browser determines which style to use for a given HTML element. IDs are said to have a high “CSS specificity” and surpass classes and element types. This means that styling against IDs is safe, if you want to be sure that your CSS rule trumps everything else (and right now we totally ignore using local styles – which is bad practice anyway).

If you want to read more about how the browser calculates specificity, I recommend W3C’s description which is short and precise (there is another good description here).

It’s perfectly fine to style against IDs, if what you are styling is HTML in a single, flat .html file. But as soon as you move into the enterprise level web apps – or just work on complex web apps in general – you are not in control of all the HTML being spit out.

The essence of this is, that it's a bad idea to base styling on IDs when working in the world of componentized web pages.

The solution: style against CSS classes

Luckily, with some planning and coordination, it’s fairly easy to make things work using CSS classes instead of IDs. And if you combine HTML element type and CSS class name, you will get a pretty good CSS specificity out of it. This way you will lower the risk of having colliding CSS styles. You can also just add more classes and element types to a selector in order to give it higher specificity, so “div.layout div.box ul li” will have higher specificity than “div.box ul li”.

There are of course cases, where it makes sense to style against IDs – e.g. a page header showing a logo image. In these cases, consider writing the plain HTML directly in the file yourself, instead of having components rendering it. Then it’s very visible to others what goes on. Oh, and you should not overwrite the Render() method in ASP.NET components to manipulate the rendered IDs – it will just get you into trouble at some point.

More thoughts and afterthoughts

In general, you should think of CSS class names as "the contract" between the developer and the designer. In a component based site, CSS designers should think: “every time an element like this shows up, I want it styled like this”. Things are not as predictable as with static HTML pages, which is why CSS people must think in a more generalizing way.

I think that the CSS specificity rules also show that CSS was really designed to deal with plain, static HTML files – rather than dynamically generated pages.

In WebForms in .NET4, Microsoft has partly solved the problem with the introduction of the ClientIDMode property, which gives the developer better control over the rendered HTML ID, including locking it down entirely by setting ClientIDMode=Static.

But the fundamental OO vs. CSS conflict is still there.