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.
Projects always win. We had a gnarly project go into production on Tuesday. Almost twenty four hours later I am carrying a cold sore on my lower left lip as a reminder of a run-down body. However, this is gross
; "Cold sores are considered to be most contagious when the blisters have burst open and have begun to weep fluid. This is because the liquid held in these blisters contains literally millions of herpes simplex virus particles." Disgusting. It is enough to make you dermitosophobic
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.
Scrymarch offers a counter argument
: "This is why I generally forbid the use of the word just
when people are making feature requests. When it comes to developers, the word I forbid is should
, but that's another story."
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.
Debuggers vs System.out.println()s
. Both have their place, personally I prefer not using the debugger and even then only when it is necessary. Then again in old, unwieldy, impenetrable codebases it is rarely you who has written the code, so it can come in handy in isolating where the failing step is occurring rather than running your eyes over the code and seeing the logical inconsistency.
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
Most Popular on South Sea Republic
The articles that have been viewed the most:
Most Popular Restaurants in Phoenix
Phoenix Eats Out
is the restaurant review site for Phoenix
and Old Town Scottsdale
which lists the modernist and contemporary restaurants, taverns and bars in the greater Phoenix area.
This is the list of the most popular restaurants pages from phoenixeatsout.com that have been viewed the most;
My personal favourite restaurants in Phoenix are AZ88
, Humble Pie
, Orange Table
, The Vig
and others coming close behind. View the complete list with the photo-journalistic style images on phoenixeatsout.com
Most Popular Hikes in Arizona
Arizona is an outdoor state and has lots of hiking in the city and around the state. Phoenix is unusual for most cities in having several large mountains in the center of the city with great hiking. Anyone who comes to Phoenix has to do the Echo Canyon trail on Camelback
and the Summit Hike on Squaw Peak
or Piesta Peak. The views of the city, suburbs and surrounding mountains are wonderful from Camelback and Piesta Peak.
For more experienced hikers there is the McDowell Mountains in North Scottsdale that has several difficult and strenuous hikes in Tom's Thumb
and Bell Pass
. Alternatively, you can hike the highest mountain in Arizona. At 12,600 feet Humphrey's Peak
is a long and difficult hike.
Alternate Australian Constitutions
Between 2004 and 2009 this site, southsearepublic.org
, was a constitutional blog based on scoop which focused on Australian and global constitutional issues.
One of the strongest aspects of it was the development of constitutions by those involved in the blog. These constitutions are the outcome:
The constitutions were built using principles from Montesquieu's separation of powers, the enlightnment's universal political rights and the ancient Athenian technology of sortition and choice by lot.
Archives For South Sea Republic
South Sea Republic started in 2004 as an Australian constitutional blog in 2004 based on scoop software. It was an immigrative outgrowth of Kuro5hin. The archives for each year since then;
The articles are ordered by views.
Who Is Cam Riley
I am an Australian living in the United States as a permanent resident.
I am a software developer by trade and mostly work in Java and jump between middleware and front end.
I originally worked in the New York area of the United States in telecommunications before moving to Washington DC and
working in a mix of telecommunications, energy and ITS. I started my own software company before heading out to
Arizona and working with Shutterfly. Since then I have joined a startup in the Phoenix area and am thoroughly enjoying myself.
I do a lot of photography which I post on this website, but also on flickr. I have a photo-journalistic website which lists
the modernist and contemporary restaurants in phoenix. I have a site on the Australian Flying Corps [AFC]
which has been around since the 1990s and which I unfortunately
lost the .org URL to during a life event; however, it is under the www.australianflyingcorps.com
The AFC website has gone through several iterations since the 90s and the two most recent are Australian Flying Corps Archives(2004-2002)
Australian Flying Corps Archives(2002-1999)
which are good places to start.
Websites Worth Reading
Websites of friends, colleagues and of interest;