Bill Scott [Netflix] comments on the differences between user experience or interface designers and the engineers which implement those designs:

Design teams feel finished when they have produced a comp and the necessary graphical assets. But the interface engineering team is just starting their work. The trick is to get interface engineers involved much earlier in the process and to get designers to stay engaged throughout the full production cycle. Engineers are production focused. Designers are often ideation focused.

I treat the Product/UE as Engineers customers. It is my job to say yes to their designs and implement them. Too often engineers think they are experts in UE and should determine how a website behaves or looks. This is incorrect. US is a specialist profession that collects data empirically through focus groups and user experience labs. User Experience professionals, while understanding technology, do not tell engineers what technology to use. The inverse should be true too.

There are limitations in the customer approach, a large being that technology cannot always implement the designer's vision. In those instances I have the engineer work directly and intimately with the UE designer to get something that will achieve the design and user experience goal within the limitations of the technology, system or whatever other engineering restraint we are facing. This has worked excellently and helped to raise the level of satisfaction in the final product that Product/UE and Engineering have.

I agree that designers need to be involved in the entire process, even though one of the downsides is the spec document tends to remain volatile and informal until the final weeks of the project when it is handed off to QA. Having the designer and engineer work together to get a feature honed will remove some of that volatility.

The other mechanism to dampen spec volatility is to treat the whole process as informal until the feature complete milestone is reached. After that point the project formalizes with a finalized spec, formal test cases and engineers hands off on feature and only engaged in quality improvements and bug fixes. By that point Engineering's customer changes from Product/UE to QA where the deliverable is feature complete and working code.

By that point features are the last thing on Engineering's mind as the codebase is put into a mode of dampening to that it can be packaged and readied for release.

The alternative to that method is to fix the spec before the project starts and make concrete scoping from that. This is great for marketing as Engineering will not commit to the project until it is absolutely certain it can do it, and that the project can be completed in the scoping provided; but really, that sucks for both designers and engineers; and projects do have to have a cowboyish element to them in order to have fun with your job.

I enjoy betting on our guys, and I enjoy telling Product/UE we can do it, or that we will have a go at it, and if we cant do it, we will work with UE to come up with something that will solve their user experience issue. This approach works well, produces strong products and is an enjoyable manner to work.

Via coding horror, quote of a quote: "the average defect detection rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of design and code inspections are 55 and 60 percent."

I would agree on that anecdotally. One of the reasons we don't do them is time normally. We are just so strapped for resources, and over worked to an extent, that once one thing is finished, it is on to the next. The rhythm allows little space for doubt or reflection unfortunately.

I disagree with the effectiveness of design reviews. We treat them largely as proof that the team is ready to start on a project. Once the project starts coding no-one looks at the design document again. The review process moves who the customer is as well.

The document ceases to be for the team, and the customer becomes the reviewers. As a consequence changes are made to the document by the team simply to get the reviewers off their backs and so they can have the design signed off on and can start coding.

Cynical? Yes, but the truth in how this all operates.

One of the issues we are facing is an expanding product line that the team is responsible for. Despite a heavy QA focus and support, I consider it our responsibility to deliver high quality code at all times. As a consequence QA is my customer for working code within our structure.

But a growing product line within the one creation path places pressure on this process. For one change deep down, we now have seven different products paths we have to test to ensure that we don't muck something up. This is only getting larger as well; we are publishing a new product next month, and embarking on a larger product which will add more products. Which will add new challenges.

As hulver notes, however, and continuing on from the opening quote, sometimes you do have to step away from the keyboard, and get explain your code structure to someone. I agree that it does improve the quality of the code.

Disclaimer, I don't have a university degree. Java world asks if you really need a college/university degree. For the most part these days - in a tight labor market - it is the price of competing for the high paid software jobs. So for a large part the rational reasons for why it isn't necessary don't matter in that instance. For those that have a resume of projects though, the degree is immaterial. From the article:

So I asked for input about the reasons someone might require a college degree as part of their company policy. I hoped to be given an "Oh! Now I understand!" moment in which I whacked myself on the head. So much for that idea.

Basically the reasons given for the requirement were lame, and did not really determine whether the person is a quality candidate or not. We have interviewed people who could answer all the technical questions but when given pen and paper could not write a line of legible code.

It probably doesn't hurt to have a degree, again it is the price of competition when you first enter the labor market, but the education itself is immaterial to the job being done for the most part; and degrees could be a lot shorter, while imparting as much useful knowledge for the work place (they should be two years max IMO) and get the students out and earning earlier.

More: Scrymarch offers a counter argument.

Since we are using PureMVC we recently had a heated discussion over whether to name the value object with a VO on the end. A kind of Flex form of Hungarian notation. One of the issues is names clashes, despite having different package names dividing up the namespaces so that each object name is different the IDE usually just displays them in the dot completion drop down as just the object name. Which can cause confusion.

I would prefer not to have to name everything with some form of end descriptor such as Command, Mediator, or Proxy but PureMVC breaks the functionality up so much that the naming ends up becoming repetitive. Also, because of the heavy use of patterns the object names tend to be meaningless unless the command, mediator or proxy is added onto the object name.

For instance a Command object is one with an execute() method that is requester agnostic and the object asking for that operation being performed doesn't know or care what the command object is doing, or going to do.

Value objects are slightly different. In the PureMVC system they are the closest thing we have to classical OOP objects. They describe a 'something' with private variables and getter and setters. So if any component in the PureMVC system should be named with a hard descriptor, it is the value objects.

A counter argument is that adding VO to the end of an object name aids readability. I consider most of this kind of readability as code litter. The reason we don't use Hungarian anymore is that it was a big mess. The convention of underscoring private variables is unnecessary in languages that have the private modifier to variables and functions. Underscoring their variables names is meaningless. So it is with package namespaces and object names.

The best argument for making the value objects carry the VO is that the IDEs tend to lump everything together in the dot completion drop downs. In my opinion this isn't a good enough argument to demand the addition of the VO identifier.

Software teams tend to be democratic to an extent and in this issue the team is slightly split. Programmers tend to treat their writing of code with care and make sure the formatting is all clean, evenly spaced and to their aesthetic liking. So something as simple as adding VO to an object descriptor can evoke some heated discussion and heels being dug in. Such is the fun of software development in teams.

The open closed principle of Object Oriented Programming [pdf]. The two attributes of this principle are "open for extension" and "closed for modification". This is the same as encapsulation where data is maintained privately and a public interface to access that data is strongly defined. Both of these are to protect the integrity of the component and not allow it to be modified willy nilly from external objects. The end result of this is that all member variables should be private.

This can be a major pain, for instance writing out Java Beans and their getter and setters can be painful. Worse, engineers discovering that typing it all out was a productivity drain instead decided we should type them out in XML first and then have them mapped to Java Beans. Such is the warped and narcissistic mind of the software engineer. The counter argument is that most getter and setters are just that, they don't place any restrictions on the argument of the setter such as validation, especially in strongly typed languages, so they end up looking like code litter.

A follow on consequence of all member variables should be private is that there should be no global variables as it can never be closed;

No module that depends upon a global variable can be closed against any other module that might write to that variable. Any module that uses the variable in a way that the other modules don't expect, will break those other modules. It is too risky to have many modules be subject to the whim of one badly behaved one.

There is always a temptation in complex systems such as javacript ones to have global variables. Occasionally they can pop out through bad scoping - such as leaving off a var when it is initialized in a method - and escape the intended block scoping.

This is from an email that was sent to me by the Australian Democrats. They are doing the right thing and seeing who on their list is interested in being maintained on a subscriber list. The problem is the NULL value in the 'Dear NULL' line.

One of the things I hate about Null is that it is a compiler level issue that has somehow propogated to databases and nearly always ends up at a customer level because it litters presentation logic. There is no way that the end user of this email should even/ever be faced with the word Null.

In my opinion it is a fundamental flaw in software engineering that this problem still persists. No wonder the inventor of null wished he had not.