At the beginning of the year i set myself the task of shipping two applications a year. It is too easy to start something and never finish it. The hardest thing is to put something into production. That means the final spit and polish that differentiates a project in an IDE and a software application that has end users.

I have an application that is only missing the backend. The UI and all the browser level interactions are complete. It is now going through phases where I am trying to reduce the UI to an ever small series of interactions. I am a big fan of minimalism as an aesthetic ideal. Additionally my experiences in software engineering and dealing with QA is that the simpler the software the less the quality issues. The screenshot below is the end of today's effort at minimalism.

Below is an earlier and fussier iteration of the user interface. Because of the larger number of buttons, the javascript was more complex to take into account all the interactions.

In the fussier iteration it was fun doing the CSS3 stuff that made it look nice. But in the end minimalism won out and the large CSS3 timer was replaced by a light grey counter. (reply)

One of the benefits of functional tests is that it removes that lost area of software development when you just swim in over design and adding stuff because you think you need it. There comes a point when the software just becomes a morass of stuff and the development becomes aimless. It is easy to fall into and it is usually where I drop what I am developing because I know I am without direction.

Functional tests being written first stop that negative area. I know the lean and test driven people argue from a point of waste and you aren't going to need it. But that aimless area is dangerous area as that is where most of the extraneous code and over design come from.

It is an important discipline to create functional tests, if not first, at least after the initial design is stubbed. It keeps focus on achieving that outcome. Unit tests are not as important at that stage of development as they are the rigor within the code. Functional tests stop wasted software development. (reply)

In Clean Code Robert Martin advocates that the team sit down and work out a code style they can all live with and then stick to it. The goal is code readability not formatting religious wars akin to emacs vs vi. Additionally, since the team chose it, you have to stick to that style because it was a group decision and your ego in what you prefer has to be swallowed. It was interesting to read how google performs this task;

Python programmers at Google must follow a strict style guideline (based on PEP8 with 2 spaced indenting). When engineers are first granted commit access to their SCM system, they must pass a style test. All code must pass through two sets of eyes before being checked in. That combined with liberal doses of unittest, pychecker and code coverage eliminates most non-algorithmic issues that might appear in python code.

Passing a style test as an introduction to the source repository is an interesting step. We have two engineering offices and two offshore operations. The offshore shops churn out code fast and don't deliver very readable code.

The Californian shop is a web-dev operation but due to engineering limitations often get brought into the middleware projects. Not that the style is bad, but you can tell it is different to the Phoenix operation.

Additionally we use a lot of contractors on different projects and product support which means there are a lot of different fingers typing into the source code at any one time and across multiple products as well.

We have a source code style document, which, is heavily indebted to Robert Martin, Steve McConnell and the Sun Standards; but it is often broken and obviously. With an offshore and floating contractor operation it is difficult to maintain standards in that way as code reviews are missed, or not done by other groups, or even not part of the sprint.

This is all part of the chaotic world of a startup coming to grips with its growth and that it will be an economic entity for a longtime to come. Dealing with longevity of its products and software systems is something to be conquered and we are working towards it. The first step is design reviews and code reviews.

Ironically our big project that is taking forever to get out into production had those steps and the code is of higher quality and more homogeneous in style for it. The core developers on that project were a tight group as well and worked within a five meter cube wall radius so communication was constant. That does make a difference. (reply)

Ryan Avent; "Which isn't to say that innovation is wealth destroying. Quite the opposite. The last two centuries' worth of unprecedented technological, institutional, and organizational innovation and associated economic growth have been one long occupational bloodbath. Thousands of job categories have perished. Millions of workers have been displaced."

Ryan argues that most jobs that are in demand today require a great deal of specialization, and it is difficult for individuals or companies to know what skills to invest in as those skills, and their jobs, may be eliminated as part of the on-going replacement of repetitive tasks by new technology.

One of the things we have seen in software in the last decade is that all aspects of software development are becoming engineering tasks. What was once done by a project manager, a business analysts, quality analysts, system administrators, etc etc is being replaced by software engineering output.

Everything is becoming a software engineering problem.

Riffing off that is new engineering processes such as continuous deployment, lean, agile etc which put the product owner and engineer face to face in short sharp bursts and then deploy the code as soon as it is finished. No lengthy QA cycle, no other departments signing off on it, just boom; done, covered by automated tests and then out into production.

The most efficient mechanism for automation is software engineering skills. We cannot find enough software engineers. The lack of engineering skills are so bad, that we have sub-par developers pushing out horrible code that is sufficiently in-flimsy that it makes it into production. It causes all sorts of maintenance and additional development issues; but it is close enough and there aren't enough good developers to cover all the needs.

Software engineering is a safe bet as the automated tasks are being developed by software engineers now and that will only expand. QA etc need engineering skills and when someone in another group shows that skill-set, they need to be stolen immediately and put under engineering's umbrella.

In Clean Code Robert Martin writes about data transfer objects and the difference between data and objects;

The issue would be a lot less confusing if data structures simply had public variables and no functions, whereas objects had private variables and public functions. However, there are frameworks and standards (eg beans) that demand that even simple data structures have accessors and mutators.

I agree with that. I don't make beans of Data Transfer Objects despite it being easy to do so through the IDE these days. I think it is unnecessary clutter. If the structure is dumb data and a mechanism to carry data around, then it doesn't need getters and setters.

I can recall when working on Flex's ActionScript that the IDE would make beans of value objects and even do a function that would remove the strong typing of the value object and present as a plain object. It made tracing the object back through the system an absolute pain.

Java has the mindset of needing beans in all sort of places but when a DTO is presented as public member variables other mechanisms that use it - such as WSDLs will put in the getters and setters anyway.

I got the error from an XAConnectionFactory; javax.jms.JMSException: [JMSPool:169822]Unable to use a wrapped JMS session in the transaction because two-phase commit is not available.

I hadn't checked the XA Connection Factory enabled when setting it up in weblogic.

Kent Beck has another awesome question; "How often do you commit code changes to the shared repository?" In my case I will commit twenty or thirty times a day. As soon as I have something done, one line even, and it passes unit tests; it gets committed. From the data on that website, it seems frequent commits are the norm.

My reasons for committing quickly and often are selfish. I don't like having to merge with a file someone else has checked in when I am trying to commit. Sending changes off continually means others have to do it to remain in sync with as I am generally closer to trunk/head.

We have two major branches; main and another large project which has been out of main for a while now. The main line has three minor branches off it that are branched for each sprint, main/trunk is effectively the release branch. The minor branches punching out every three weeks put some pressure on continuous integration as we use Bamboo and configuration for it is largely manual.

One of ten signs of crappy PHP code is; "The authors try to use Design Patterns". The article argues that quickly looking at a design pattern attempt is enough to determine if the developers know what they are doing or not. I have seen poor developers shoe-horn patterns in and basically made the code unreadable, overly complex, with too much indirection and over engineered.

Patterns are useful but they are for complex situations that need to be solved with a consistent mechanism. Simple code problems deserve simple solutions and don't need the complexity, engineering or indirection and abstraction of a design pattern.

Unfortunately design patterns in software are fashion. They do solve a purpose, but the reason everyone implements singletons, or uses it as a question in an interview, is that it is the simplest one. Most are complex to implement, and complex to understand once implemented.

Young developers shoe-horning design patterns in all over the place where it is unnecessary or a simpler approach would suffice is an issue.

Kent Beck's next question after deployment frequency is; "How often do you run functional tests?" We use Bamboo as our continuous integration tool. We have our middleware functional tests hooked into the continuous integration process. We scheduled them to run every night.

Our functional tests are JUnit based and comprise about two hundred tests that exercise the middleware through the webservice and remote interface layers. We use them to change state in the entire system and then as part of the assert process we query the external systems either through webservices or jdbc to make sure that the data or state change was recorded correctly.

We have been having problems with the lower environments not being able to handle the frequency of queries to the system. A lot of our functional tests fail due to time out issues that are based around a lack of horsepower in the lower development environments. We have one vendor in particular whose software doesn't handle running on a virtual machine very well and is a major cause of the slowdowns and false positives.

Again, this is part of our strategy to get to the point of continuous deployment.

Kent Beck did a quick study at how quickly people were publishing their applications to production. There is some interesting results considering that some people did it once a year. I shouldn't laugh at that we have a project that is in its ten month, so by that reckoning it is on a once a year track.

The previous place I worked at had a rigid production schedule. The first Tuesday of every month was release day. It would start at 11:00 and any group that had anything going out to production had to remain at their desks all day. Lunch was bought.

It was a pretty slick operation. There was rarely any hitches. There was also a minor release cycle which was performed in the afternoon of the third Tuesday of the month. This was usually patches and other fixes that had gone in and was rarely new features or new applications.

The place I worked at before that was adhoc. Whenever something was worth releasing, out it would go. It might be something that was needed that night, or a major feature, but once it was ready, out it went that night. It worked quite well. Good enough that often hot fixes were sent in during the middle of the day. The outage was usually at worst a couple of minutes so no-one minded. It was an in-house app though with a user-base of probably 300 people, so ramifications were not wide if there was a short outage.

The current place I am at tends to releases at the end of each sprint. Once it is through QA/Stage then it is pretty much published there and then. Not all deployments affect all parts of the application, so some go in during the day, but the ones that affect the largest in-house user group tend to be deployed outside of business hours.

Our goal is continuous deployment. We have a long way to go to achieve it. The tools that we are developing to support that strategy are starting to make their way up the environment chain from dev integration to QA and Stage; eventually we will have it so production is a part of our automated tool set and integration process.