If you've got any real world programming experience then no doubt at some point you've had to resort to some quick and dirty fix to get a problem solved or a feature implemented while a deadline loomed large. Game developers often experience a horrific "crunch" (also known as a "death march"), which happens in the last few months of a project leading up to the game's release date. Failing to meet the deadline can often mean the project gets cancelled or even worse, you lose your job. So what sort of tricks do they use while they're under the pump, doing 12+ hour per day for weeks on end?
Below are some classic anecdotes and tips - many thanks to Brandon Sheffield who originally put together this article on Gamasutra. I have reposted a few of his stories and also added some more from newer sources. I have also linked on each story to the author's home page or blog wherever possible.
1. The programming antihero - Noel Llopis
I was fresh out of college, still wet behind the ears, and about to enter the beta phase of my first professional game project -- a late-90s PC title. It had been an exciting rollercoaster ride, as projects often are. All the content was in and the game was looking good. There was one problem though: We were way over our memory budget.
Since most memory was taken up by models and textures, we worked with the artists to reduce the memory footprint of the game as much as possible. We scaled down images, decimated models, and compressed textures. Sometimes we did this with the support of the artists, and sometimes over their dead bodies.
We cut megabyte after megabyte, and after a few days of frantic activity, we reached a point where we felt there was nothing else we could do. Unless we cut some major content, there was no way we could free up any more memory. Exhausted, we evaluated our current memory usage. We were still 1.5 MB over the memory limit!
At this point one of the most experienced programmers in the team, one who had survived many years of development in the "good old days," decided to take matters into his own hands. He called me into his office, and we set out upon what I imagined would be another exhausting session of freeing up memory.
Instead, he brought up a source file and pointed to this line:
static char buffer[1024*1024*2];
"See this?" he said. And then deleted it with a single keystroke. Done!
He probably saw the horror in my eyes, so he explained to me that he had put aside those two megabytes of memory early in the development cycle. He knew from experience that it was always impossible to cut content down to memory budgets, and that many projects had come close to failing because of it. So now, as a regular practice, he always put aside a nice block of memory to free up when it's really needed.
He walked out of the office and announced he had reduced the memory footprint to within budget constraints -- he was toasted as the hero of the project.
As horrified as I was back then about such a "barbaric" practice, I have to admit that I'm warming up to it. I haven't gotten into the frame of mind where I can put it to use yet, but I can see how sometimes, when you're up against the wall, having a bit of memory tucked away for a rainy day can really make a difference. Funny how time and experience changes everything.
2. Cache it up - Andrew Russell
To improve performance when you are processing things in a tight loop, you want to make the data for each iteration as small as possible, and as close together as possible in memory. That means the ideal is an array or vector of objects (not pointers) that contain only the data necessary for the calculation.
This way, when the CPU fetches the data for the first iteration of your loop, the next several iterations worth of data will get loaded into the cache with it.
There's not really much you can do with using fewer and faster instructions because the CPU is as fast as its going to get, and the compiler can't be improved. Cache coherence is where it's at - this article contains a good example of getting cache coherency for an algorithm that doesn't simply run through data linearly.
3. Plan your distractions - Jay Barnson
The Internet is one of the greatest tools ever invented for both improving and destroying productivity. Twitter and forums and blogs and instructional websites can be extremely motivational and educational, but they can also be a distraction that completely destroys all hope of ever getting anything done. One thing I’ve done in the past which has proven pretty successful is to stick to a plan for when I can spend some minutes checking email and Twitter, or play a quick game or something. Either at the completion of a task, or after a period of time (say one five-minute break every hour). Otherwise, the browser’s only use is for reading reference manual pages, if necessary. That way I turn a potential distraction into a motivating tool.
4. Collateral damage - Jim Van Verth (@cthulhim)
Don't know how many remember Force 21, but it was an early 3D RTS which used a follow cam to observe your current platoon. Towards the end of the project we had a strange bug where the camera would stop following the platoon -- it would just stay where it was while your platoon moved on and nothing would budge it. The apparent cause was random because we couldn't find a decent repro case. Until, finally, one of the testers noticed that it happened more often when an air strike occurred near your vehicles. Using that info I was able to track it down.
Because the camera was using velocity and acceleration and was collidable, I derived it from our PhysicalObject class, which had those characteristics. It also had another characteristic: PhysicalObjects could take damage. The air strikes did enough damage in a large enough radius that they were quite literally "killing" the camera.
I did fix the bug by ensuring that cameras couldn't take damage, but just to be sure, I boosted their armor and hit points to ridiculous levels. I believe I can safely say we had the toughest camera in any game.
5. The blind leading the blind - Maurício Gomes
At university there was a team that made a FPS flash game. For some bizarre reason, the programmer, instead of checking if the character was colliding with the wall and stop you going there, he did the inverse, he checked if there was a wall, and only allowed you to move parallel to it!
This sparked a bizarre bug: in crossings or T junctions in the level, you could not actually cross, only turn to the passage on your left or right. The deadline was closing, and they had no idea on how to fix it.
Then the team writer fixed the issue; he told the artist to add an animation of hands touching the walls, and then he added in the background story that the main character was blind and needed to constantly touch the walls to know where he was going.
6. You wouldn't like me when I'm angry - Nick Waanders
I once worked at THQ studio Relic Entertainment on The Outfit, which some may remember as one of the earlier games for the Xbox 360. We started with a PC engine (single-threaded), and we had to convert it to a complete game on a next-gen multi-core console in about 18 months. About three months before shipping, we were still running at about 5 FPS on the 360. Obviously this game needed some severe optimization.
When I did some performance measurements, it became clear that as much as the code was slow and very "PC," there were also lots of problems on the content side as well. Some models were too detailed, some shaders were too expensive, and some missions simply had too many guys running around.
It's hard to convince a team of 100 people that the programmers can't simply "fix" the performance of the engine, and that some of the ways people had gotten used to working to needed to be changed. People needed to understand that the performance of the game was everybody's problem, and I figured the best way to do this is with a bit of humor that had a bit of hidden truth behind it.
The solution took maybe an hour. A fellow programmer took four pictures of my face -- one really happy, one normal, one a bit angry, and one where I am pulling my hair out. I put this image in the corner of the screen, and it was linked to the frame rate. If the game ran at over 30fps, I was really happy, if it ran below 20, I was angry.
After this change, the whole FPS issue transformed from, "Ah, the programmers will fix it." to, "Hmm, if I put this model in, Nick is going to be angry! I'd better optimize this a little first." People could instantly see if a change they made had an impact on the frame rate, and we ended up shipping the game at 30fps.
7. Its not a bug, its a feature! - Philip Tan
I worked on an RPG in which we were trying to get the NPCs (Non-player Characters) to spot when you were in range, walk up to you, and strike up a conversation with you by activating the dialog system.
We forgot to add code to distinguish NPCs from PCs (Player Characters), so we'd walk into town and all the NPCs would be talking with each other. Because all NPC AI code used the same dialog template, they actually got a few sentences in before the conversations became nonsensical. And because character dialog was broadcast, you could read everything they said if you were in range.
We decided to turn that bug into a major feature.
8. Dirty deeds - Tim Randall (Developer @ Encore)
The engine team at Gremlin Interactive used to keep a single glove in their office. When someone asked why it was there, they were told it was only used when someone was about to type some really dirty code. It wasn't so much a case of not wanting to leave fingerprints but rather not wanting to actually touch the dirtiest fixes!
9. Explicit conditional hinting - ZorbaTHut
A very, very low-level tip, but one that can come in handy... most compilers support some form of explicit conditional hinting. GCC has a function called __builtin_expect which lets you inform the compiler what the value of a result probably is. GCC can use that data to optimize conditionals to perform as quickly as possible in the expected case, with slightly slower execution in the unexpected case.
if(__builtin_expect(entity->extremely_unlikely_flag, 0)) {
// code that is rarely run
}
I've seen a 10-20% speedup with proper use of this.
10. Object-ive oriented programming - Anonymous
Back at a game studio, I think it was near the end of the project, we had an object in one of the levels that needed to be hidden. We didn't want to re-export the level and we did not use checksum names. So right smack in the middle of the engine code we had something like the following:
if( level == 10 && object == 56 )
{
HideObject();
}
The game shipped with this in.
Maybe a year later, an artist using our engine came to us very frustrated about why an object in their level was not showing up after exporting. The level they had a problem with resolved to level 10. I wonder why?
11. Stack vs Heap - Torbjörn Gyllebring
Stack allocation is much faster than heap allocation since all it really does is move the stack pointer. Using memory pools, you can get comparable performance out of heap allocation, but that comes with a slight added complexity and its own headaches.
Also, stack vs heap is not only a performance consideration; it also tells you a lot about the expected lifetime of objects. The stack is always hot, the memory you get is much more likely to be in cache than any far heap allocated memory.
Downside of the stack is that it is actually a stack. You can't free a chunk of memory used by the stack unless it is on top of it. There's no management, you push or pop things on it. On the other hand, the heap memory is managed: it asks the kernel for memory chunks, maybe splits them, merges thems, reuses them and frees them. The stack is really meant for fast and short allocations.
12. I'm a programmer, not an artist - Damian Connolly
For indie / solo developers who are working on an iPhone or Android game on their own, while you're looking for an artist etc, you should be developing your game at the same time. Use programmer art, stand-ins, free sprites anything. Most of the time, before even thinking about final assets, I just want something up and running quickly to see if it's fun. Prototype the crap out of it and find the game. Then, when the gameplay's locked down, you can start putting in the proper art. Doing it the other way around leads to lost money, and work that needs to be redone multiple times, which aside from harming your project, sucks your motivation to finish it (and if you're making a game to get a job, showing that you can finish a project is a good thing). Another tip if you're lacking upfront finance is to find a freelance game artist who will accept a revenue sharing deal, e.g. typically something like 30% of game revenue, payable once it gets published to the AppStore.
13. Remove unnecessary branches - tenpn
On some platforms and with some compilers, branches can throw away your whole pipeline, so even insignificant if() blocks can be expensive.
The PowerPC architecture (PS3/x360) offers the floating-point select instruction, fsel. This can be used in the place of a branch if the blocks are simple assignments:
float result = 0;
if (foo > bar) { result = 2.0f; }
else { result = 1.0f; }
Becomes:
float result = fsel(foo-bar, 2.0f, 1.0f);
When the first parameter is greater than or equal to 0, the second parameter is returned, else the third. The price of losing the branch is that both the if{} and the else{} block will be executed, so if one is an expensive operation or dereferences a NULL pointer this optimisation is not suitable. Sometimes your compiler has already done this work, so check your assembly first.
14. Hack the stack - Steve DeFrisco
I was one of a few interns at IMAGIC in 1982-83. We were all doing Intellivision carts. One of the programmers had to leave to go back to school, and I was chosen to fix the random crash bug in his game. It turned out to be a stack overflow in the timer interrupt handler. Since the only reason for the handler was to update the *display* of the on-screen timer, I added some code to test the depth of the stack at the beginning of the interrupt routine. If we were in danger of overflowing the stack, return without doing anything. Since the handler was called multiple times per second, the player never noticed, and the crash was fixed.
15. Meet my dog, "Patches" - Mick West
There's an old joke that goes something like this:
Patient: "Doctor, it hurts when I do this."
Doctor: "Then stop doing it."
Funny, but are these also wise words when applied to fixing bugs? Consider the load of pain I found myself in when working on the port of a 3D third person shooter from the PC to the original PlayStation.
Now, the PS1 has no support for floating point numbers, so we were doing the conversion by basically recompiling the PC code and overloading all floats with fixed point. That actually worked fairly well, but where it fell apart was during collision detection.
The level geometry that was supplied to us worked reasonably well in the PC version of the game, but when converted to fixed point, all kinds of seams, T-Junctions and other problems were nudged into existence by the microscopic differences in values between fixed and floats. This problem would manifest itself in one case with the main character touching a particular type of door in a particular level in a particular location; rather than fix the root cause of the problem, I simply made it so that if he ever touched the door, then I'd move him away, and pretend it never happened. Problem solved.
Looking back I find this code quite horrifying. It was patching bugs and not fixing them. Unfortunately the real fix would have been to go and rework the entire game's geometry and collision system specifically with the PS1 fixed point limitations in mind. The schedule was initially aggressive, and since we always seemed close to finishing, the quick patch option won over against a comprehensive (but expensive) fix.
But it did not go well. Hundreds of patches were needed, and then the patches themselves started causing problems, so more patches were added to turn off the patches in hyper-specific circumstances. The bugs kept coming, and I kept beating them back with patches. Eventually I won, but at a cost of shipping several months behind schedule, and working 14 hour days for all of those several months.
That experience soured me against "the patch." Now I always try to dig right down to the root cause of a bug, even if a simple, and seemingly safe, patch is available. I want my code to be healthy. If you go to the doctor and tell him "it hurts when I do this," then you expect him to find out why it hurts, and to fix that. Your pain and your code's bugs might be symptoms of something far more serious. The moral: Treat your code like you would want a doctor to treat you; fix the cause, not the symptoms.
16. Identity crisis - Noel Llopis
This scene is familiar to all game developers: It's the day we're sending out the gold candidate for our Xbox 1 game. The whole team is playtesting the game all day long, making sure everything looks good. It's fun, it's solid, it's definitely a go in our minds.
In the afternoon, we make the last build with the last few game-balancing tweaks, and do one last playthrough session when disaster strikes: The game crashes hard! We all run to our workstations, fire up the debugger, and try to figure out what's going on. It's not something trivial, like an assert, or even something moderately hard to track down, like a divide by zero. It looks like memory is garbage in a few places, but the memory reporting comes out clean. What's going on?
One dinner and many hours later, our dreams of getting out on time shattered, we manage to track it down to one data file being loaded in with the wrong data. The wrong data? How's that possible? Our resource system boiled down every asset to a 64-bit identifier made out of the CRC32 of the full filename and the CRC32 of all the data contents. That was also our way of collapsing identical resource files into a single one in the game. With tens of thousands of files, and two years of development, we never had a conflict. Never.
Until now, that is.
It turns out that one of the innocent tweaks the designers had checked in that afternoon made it so a text file had the exact same filename and data CRC as another resource file, even though they were completely different!
Our hearts sank to our feet when we recognized the problem. There's no way we could change the resource indexing system in such a short period of time. Even if we pulled an all-nighter, there was no way to know for sure that everything would be stable in the morning.
Then, as quickly as despair swept over us, we realized how we could fix this on time for the gold candidate release. We opened up the text file responsible for the conflict, added a space at the end, and saved it. We looked at each other with huge grins on our faces and said:
"Ship it!"
The extra space meant the CRC32 checksum of the text file was altered and therefore no longer conflicted with the other resource.
17. HexEdit to the rescue - Ken Demarest
Back on Wing Commander 1 we were getting an exception from our EMM386 memory manager when we exited the game. We'd clear the screen and a single line would print out, something like "EMM386 Memory manager error. Blah blah blah." We had to ship ASAP. So I hex edited the error in the memory manager itself to read "Thank you for playing Wing Commander."
18. 8-bit audio stomper - Toonse
For a launch product of a certain console I had a nasty bug report from QA that took 20+ hours to reproduce. Finally (with 24 hours left to go to hit console launch) tracked it down to some audio drivers in the firmware that were erroneously writing 1 random byte "somewhere" at random times where the "somewhere" was always in executable code space. I finally figured out that any given run of the game that "somewhere" was always the same place, luckily. 1st party said sorry, can't fix it in time as we don't know why it's being caused! So I shipped that game with stub code at the very start of main that immediately saved off the 1 byte from the freshly loaded executable in the place I knew it would overwrite for that particular version of the exe. There was then code that would run each frame after audio had run and restore that byte back to what it should be just in case it had been stomped that frame. Good times! We hit launch.
To this day I still feel very very dirty about this hack, but it was needed to achieve the objectives and harmed no-one :)
19. Rainy day server pool - Potatolicious
I used to work for a company that had a horrific hardware requisition policy. If your team needed a server, it had to go through a lengthy and annoying approvals process - and even then, it took months before Infrastructure would actually provide said servers.
In other words, when a project gets handed down from above to launch in, say, 3 months, there's no way in hell you can get the servers requisitioned, approved, and installed in that time. It became standard practice for each team to slightly over-request server capacity with each project and throwing the excess hosts into a rainy day pool, immediately available and repurposeable as required.
New servers will still get requested for these projects, but since they took so long to approve, odds are they'd go right into the pool whenever they actually arrived, which sometimes took up to a year.
Of course, it was horrifyingly inefficient. Just on my team alone I think we had easily 50 boxes sitting around doing nothing (and powered on to boot) waiting to pick up the slack of a horrendously broken bureaucracy.
20. Bit shifting magic - Steven Pigeon
In order to avoid stalls in the processor pipeline due to branching, one can often use a branchless equivalent, that is, code transformed to remove the if-then-elses and therefore jump prediction uncertainties. E.g. a straightforward implementation of abs( ) in C might be
inline int abs(int x)
{
return (x<0) ? -x : x;
}
Which is simple enough but contains an inline if-then-else. As the argument, x, isn’t all that likely to follow a pattern that the branch prediction unit can detect, this simple function becomes potentially costly as the jump will be mispredicted quite often.
How can we remove the if-then-else, then? One solution is to use the right shift operator (>>) and the bitwise XOR operator (^) as following:
inline int abs_no_branch(int x)
{
int m = (x >> (8 * sizeof(int)-1));
return ((x ^ m) - m);
}
Where the expression (8 * sizeof(int) - 1) evaluates to 15, 31, or 63 depending on the size of integers on the target computer.
Further detailed reading about this technique here: Branchless Equivalents of Simple Functions.
Follow @dodgy_coder on Twitter
Saturday, February 11, 2012
Sunday, January 15, 2012
The Promise of HTML5
A popular lightweight framework has sprung up on top of WebGL called three.js.The aim of the project is to create a lightweight 3D engine with a very low level of complexity; in other words, for developers who are not experienced with 3D graphics coding. The engine can render using <canvas>, <svg> and also WebGL. It is one of the most comprehensive WebGL frameworks, covering matrices, scenes, meshes, materials, shadows, voxels, fog, and more. Many of the Chrome WebGL demos linked above use it and there's a list of demos on the three.js github page. These demos are absolutely mind blowing - I ran them inside Chrome with a reasonably old graphics card (a three year old GEForce 9600 GT) and the results were incredible - all ran at around 60 frames per second.
A couple of real standouts here:
Floating soap bubbles - fresnel shader demo (rotate view with mouse)
Model of a head - normalmap demo (rotate view with mouse)
Model of Walt Disney - cube mapping and texture demo (rotate view with mouse)
Follow @dodgy_coder
Subscribe to posts via RSS
Wednesday, January 4, 2012
Modern Cross Platform Development
Why isn't there a modern technology available for using the same codebase to produce native apps on all of the currently popular platforms - I'm talking iOS (iPhone/iPad/iPod Touch), Android, Windows, Mac and Linux?
That was my original question before I started looking, and since then I've discovered there actually are plenty of new options out there for cross platform development catering for all of the above platforms.
A Brief History of Desktop UI Toolkits
In the 1980's the problem of a cross platform desktop user interface was for the most part solved by the X Window system, known as X11, (1984-) along with one of the first widget toolkits, Motif (1989-), which was built on top of X11. Back then, the dominant platforms used by business were Microsoft Windows and the various flavours of Unix, like Sun Solaris, HP-UX, IBM's AIX etc (later Linux came along and maintained full support for X11 and Motif). Developers who wanted to target multiple platforms such as these had this option of developing one codebase, usually written in C/C++, using X11 and/or Motif. The UI code for the most part could remain the same and the application just needed to be recompiled with the provided X11 libraries.
Since then Motif has pretty much faded into the background and been replaced with newer widget toolkits, still built on top of X11, including Qt (1991-), wxWidgets (1992-) and GTK+ (1998-). These now run on many different platforms and bindings are available for many, many languages, including for their native C or C++.
These three free open source toolkits have been successful for the desktop application case but looking towards mobile and tablet platforms, these toolkits don't currently have the support there to take them into the future.
Qt
Native language: C++
Platforms: iOS (unofficial), Windows, Mac, Linux.
Probably the C++ based Qt widget toolkit is the most well established way of writing desktop cross platform applications. Smartphone support isn't really there yet, but there is an unofficial port to iOS. Linux's KDE desktop environment is written with the Qt toolkit. Many significant apps have been developed with Qt, including Autodesk Maya, VLC media player, Mathematica, Virtual Box and Skype. Qt is now owned by Nokia (although is still open source), and there was a release of a new version recently (Qt 4.8).
GTK+
Native language: C
Platforms: HTML5 (unofficial), Windows, Mac, Linux.
The C-based GTK+ widget toolkit is also a very well established way of writing cross platform desktop apps. Smartphone support isn't there, but there is an unofficial port to HTML5. GTK+ powers Chromium on Linux, the open source forerunner to Google's Chrome browser. The GNOME desktop environment is written with the GTK+ toolkit. The other notable app written with GTK+ is the one that launched the toolkit itself, GIMP, an open source bitmap image editor.
wxWidgets
Native language: C++
Platforms: iOS, Windows, Mac, Linux.
A C++ native mode toolkit that provides a thin abstraction to a platform's native widgets. It was originally developed as a desktop GUI toolkit in the same vein as GTK+ and Qt and support for iOS is still beta. There are a number of notable apps developed with wxWidgets including BitTorrent, Audacity, TortoiseCVS and RapidSVN.
Java and Silverlight
Sun's Java Swing UI Library (1997-) and Microsoft's Silverlight (2007-) were both attempts at "write once, run anywhere" (WORA) technology that provided a rich user interface library. Although technically successful, they failed in their attempt to become the ubiquitous technology that everyone uses to develop UIs. They both attempted to replace the 'native' look of apps developed on a particular platform and instead impose their own look and feel based on graphical primitives, which although being more powerful for developers, users on the whole didn't like.
As Johannes Fahrenkrug discusses here, people actually want to run Windows apps that look like Windows apps, and run MacOS apps that look like MacOS apps. To be fair, the Java Swing UI has actually undergone a lot of advances since it was first released and can now generate apps that do look perfectly native on all desktop platforms. The problem may be however that people's original experience of early Swing apps having a slow and inconsistent UI might have put them off using other Java apps and so contributed to its demise.
In the case of Microsoft's Silverlight and WPF, although not officially dead yet, they are now taking a back seat to newer technologies that were released by Microsoft at the September 2011 Build conference; Windows 8 allow developers to create new style 'Metro' applications by using either web technology (HTML5/JavaScript/CSS) or a traditional language - C#, VB.NET or C/C++ paired up with XAML for describing the UI. There's more detail about this topic on StackOverflow here for those interested.
The Rise of Web Applications and the App Store
The two big changes since the desktop UI toolkit days has been the rise of browser-based web applications and more recently the rise of downloadable apps running on smartphones and tablets such as Apple's iOS (powering the iPod touch, iPhone and iPad devices) along with Google's Android (powering a vast array of different smartphones and tablets from many hardware vendors). Google's recent Chrome OS also deserves a mention for creating an OS around the browser itself. These new class of devices offer a quick method of downloading, paying for and installing apps (often with just one click) and appear in the easy to use 'App Store' on iOS and 'Android Marketplace' on Android.
Microsoft is getting in on the App Store action a little late with its 'Windows Store' for Windows 8, which will be appearing some time in 2012. Its thought by Hal Berenson (a former Distinguished Engineer at Microsoft) that the upcoming Windows Phone 8 OS will be based on the same technology as Windows 8 and hence will unify the development platform for Microsoft's desktop, tablet and smartphone operating systems. This will likely be announced some time in 2012, probably at the same time Microsoft launches the 'Windows Store'. This will mean Windows 8's new 'Metro' style apps on the Windows Store will run on phones, desktops and tablets - something that neither Apple nor Google can lay claim to, just yet. Add in the possibility of an XBox update which adds support for running Metro apps, and you have a huge carrot which will make the unified Windows 8 platform very attractive to both application and game developers.
Choosing Your Platform - Desktop, Web or Mobile Application?
When choosing your platform, if you need full access the underlying file system, or access to hardware devices like serial ports, microphones, webcams, etc, then you may be better off staying with a desktop application. If you need platform independence on top of this then you can go with one of the traditional widget library technologies like wxWidgets, GTK+ or Qt to provide a full cross platform UI solution.
Alternatively, if you don't need so much access to hardware and can remain restricted to the browser, then HTML5 and JavaScript may be the way to go. Browser based web applications have their own set of problems however, including the browser incompatibilities, varying support for the HTML/CSS web standards and the Document Object Model (DOM). In addition, web application development generally makes it harder to create rich UI apps than for desktop or mobile applications. HTML5 will provide massive improvements, but web apps are still running in a browser and so will always remain sandboxed and limited in what they can achieve (no access to file system, serial ports, microphone, webcam, etc.).
The main advantage of the browser app however, and its a massive one, is that its everwhere and supported by every device, so if HTML5 takes off, then it could become the defacto standard for developing apps of any kind, desktop or not. As Jeff Atwood discusses in his seminal blog post All Programming is Web Programming; "the web is the most efficient, most pervasive, most immediate distribution network for software ever created - its almost completely frictionless". As Atwood mentions, more and more users gravitate towards preferring to run their apps inside the browser, on smartphones and on tablets where things 'just work' and there's generally nowhere near as much friction caused by the traditional desktop software setup and update process.
A third option available now is the cross platform mobile development SDK as detailed below (Mono, Appcelerator Titanium, Rhodes, PhoneGap, MoSync, Moai, Corona SDK and JUCE). Smartphone and tablet based applications are taking off, and these SDKs allow you to write once and run on any of these new class of devices, as well as in some cases also being able to run on the traditional desktop. These would seem to offer some of the 'power' of the desktop in terms of native code execution speed and access to hardware functionality, along with the enourmous 'frictionless' benefit that you get when publishing to an app store, where installing an app is literally a one click operation.
Mono
Native language: C#
Platforms: iOS, Android, Windows, Mac, Linux, Browser (e.g. via ASP.NET WebForms or MVC).
Cost: Windows, Mac & Linux: free. Android and iOS: from US$399 each. Free trial available.
License: LGPL/GPL/X11 combination. Commercial license available.
Source: Mono for Windows/Mac/Linux is open source. Mono for iOS/Android is closed source.
The C# based Mono cross platform library allows apps to be built using purely C#. However this is not strictly a cross platform UI library, since each supported platform has its own different set of Mono C# UI libaries, each with their own capabilities. The idea is that you build your software using the MVC (Model View Controller) pattern, so that the Model and Controller components (both written in C#) can be shared across all platforms without any changes. Only the View component needs to be re-written for each platform (again, in C#). Mono targets both mobile and desktop apps, however if you are just looking at developing a desktop application, then Mono probably isn't a big improvement over GTK+ or Qt, after all a well written C++ Library (with a Model and Controller component for example) will enjoy the same capability to be shared across more than one platform if you use Qt or GTK+ and then you wouldn't need a different UI library on each platform to create your view. There are several advantages that Mono has over Qt or GTK+ however - firstly in leveraging a team's existing knowledge (and codebase) of C# which is a popular language. Secondly, being able to target iOS, Android and the browser. Lastly, via Mono's .NET CLR implementation (Common Language Runtime), code is compiled into modules of bytecode, which are binary compatible across all the supported platforms.
There is also an open source library for Mono called MonoGame which lets you port with minimal effort XNA based games (which originally target the .NET platform and run only on Windows Mobile, Windows and XBox) to any of the Mono platforms such as MacOS, Linux, iOS and Android.
Appcelerator Titanium
Native language: JavaScript, Python and Ruby
Platforms: iOS, Android, Windows, Mac, Linux.
Cost: Community Edition is free. Indie Edition (extra APIs, help, support): US$499 per year.
License: Apache Public License v2
Source: Open source
An open-source solution which allows you to use web development languages (HTML, JavaScript, CSS, Python and Ruby) to build mobile and desktop apps. App data can be stored in the cloud or on the device, and apps can take full advantage of hardware, particularly camera and video camera capability. Appcelerator apps go through a complex compilation and optimization process which result in it creating apps that look, feel, and perform just like native apps, because you are using native UI components... so an iPhone app developed with Titanium will actually feel like an iPhone app. They also offer an API repository marketplace to buy and sell code to extend Titanium. One of the downloadable components allows you to develop your app using an MVC (Model View Controller) pattern. There is an active developer community Q&A site for Titanium developers which is similar in usage to StackOverflow.
Rhodes
Native language: Ruby
Platforms: iOS, Android, Windows Mobile, Blackberry.
Cost: Free
License: MIT License
Source: Open source
Rhodes is an open source, Ruby-based framework that allows the development of native apps for a wide range of smartphone devices and operating systems. The framework lets you write your code once and use it to quickly build apps for every major smartphone. Apps can take full advantage of available hardware, including GPS and camera, as well as location data. Rhodes enforces a strict MVC (Model View Controller) pattern on your apps. Views are written in HTML5 while Controllers and Models are written in Ruby.
PhoneGap
Native language: HTML5/JavaScript
Platforms: iOS, Android, Windows Mobile, Blackberry, Symbian, Palm.
Cost: Free
License: Apache License, Version 2.0
Source: Open source
PhoneGap is an open source framework that helps you develop apps for smartphones using web development languages such as JavaScript and HTML5. It also allows for access to hardware features including GPS/location data, accelerometer, camera, sound and more. PhoneGap lets you take a web app, run it in a UIWebView, and through javascript you can access iPhone features such as the camera an accelerometer. This means that it won't necessarily have the look and feel of a native app (like the other cross platform SDKs listed here). The idea is that you develop your web app like you normally do, and then use PhoneGap to 'bridge the gap' to the phone, and give you access to phone's hardware, that traditionally you couldn't access from a web-only app.
MoSync
Native language: C++
Platforms: iOS, Android, Windows Mobile, Blackberry, Symbian.
Cost: Free for Indie developers. From €199 (Euros) per year for Enterprise developers.
License: GPL v2. Commercial license available.
Source: Open source
The MoSync Mobile SDK is a cross-platform mobile application development SDK which allows the development of native apps. Free open-source, it is based on C++ but allows development also in HTML5 and JavaScript. MoSync provides access to a wide range of underlying device functionality, via a C++ SDK or optionally via JavaScript. It requires probably a greater degree of software skill from the developer, but in principle can enable a rich variety of different kinds of application.
Moai
Native language: Lua
Platforms: iOS, Android, Chrome Web Store, Windows, Mac, Linux.
Cost: Free
License: Common Public Attribution License Version 1.0 (CPAL)
Source: Open source
Although intended to be a mobile game development SDK, I think it deserves a mention here due to its unique scripted approach to cross platform development. Games developed with Moai run on iOS and Android as well as the Chrome Web Store, Windows, Mac and Linux. Designed to be programmed with the Lua scripting language, Moai is designed for experienced game developers who wish to use Lua for mobile development. The Moai framework itself is written in C++ and is intended to be called from the Lua scripting language, but can also be called from any other language supported by the host platform. The Lua script is run as interpreted byte code, but since very few Lua instructions are processed among all the input handling, this means that rendering, animation, collision detection, and physics math runs natively. Moai's physics engine for example is the Box2D open source C++ library. Moai is free and open source, however to build apps for iOS devices you'll need the iOS SDK and the Xcode IDE (presumably running on MacOS) and be a member of the Apple iOS developer program (US$99/year). To build apps for Android you'll need the Android SDK, the Eclipse IDE and an Android device.
Corona SDK
Native language: Lua
Platforms: iOS, Android, Kindle Fire, Nook Color.
Cost: US$199/year for Android. US$199/year for iOS. $349/year for all platforms. Free trial available.
License: Commercial, price as above.
Source: Closed source
A similar toolkit to Moai in that its primarily aimed at game developers, and apps are written with the Lua scripting language. Corona SDK was developed by two former Adobe mobile engineers and has been in development since 2007. It features a proprietary OpenGL-ES rendering engine, which allows for full hardware acceleration of graphics, including sprites that animate at full GPU speed. The Corona physics engine is built around Box2D as with Moai. Its free to try Corona and run your apps in a simulator on your desktop computer, but to build an app and publish it to an App Store, you'll need to pay a yearly subscription fee (of either US$199 per year for Android or iOS or the premium subscription of US$349 for all platforms). Your apps are built "in the cloud" on Corona's server. Note that if you are developing for iOS you'll still need to pay the yearly Apple iOS developer program fee which is currently US$99. There seems to be extensive documentation available for Corona and an active developer community forum. There has been a recent push to promote Corona for use not only for developing games but also for general apps and also interactive ebooks.
JUCE
Native language: C++
Platforms: Windows, MacOS, Linux, iOS, Android (Note that Android support is a work in progress).
Cost: Free for GPL license. Commercial license from £399 (UK pounds) per product.
License: GPL. Commercial license available.
Source: Open source
JUCE is an all-encompassing C++ class library for developing cross-platform software. Its designed to contain everything you're likely to need to create most applications, and is particularly well-suited for building highly-customised GUIs, and for handling graphics and sound. JUCE is developed by Raw Material Software and consists of a small team of developers based in London, England, founded by Julian Storer in 1999, who is still the primary developer today. It would probably be best suited to experienced C++ developers. Julian Storer himself is a professional C++ coder with over 15 years of C++ experience; he takes pride in the fact the source for JUCE is literate, coherent, cross-platform and high quality. Adding JUCE to your C++ application is very simple - the easiest way involves simply including juce.h in your files and adding a single .cpp file to your project. No need to compile any libraries or worry about dependencies.
Follow @dodgy_coder
Subscribe to posts via RSS
That was my original question before I started looking, and since then I've discovered there actually are plenty of new options out there for cross platform development catering for all of the above platforms.
A Brief History of Desktop UI Toolkits
In the 1980's the problem of a cross platform desktop user interface was for the most part solved by the X Window system, known as X11, (1984-) along with one of the first widget toolkits, Motif (1989-), which was built on top of X11. Back then, the dominant platforms used by business were Microsoft Windows and the various flavours of Unix, like Sun Solaris, HP-UX, IBM's AIX etc (later Linux came along and maintained full support for X11 and Motif). Developers who wanted to target multiple platforms such as these had this option of developing one codebase, usually written in C/C++, using X11 and/or Motif. The UI code for the most part could remain the same and the application just needed to be recompiled with the provided X11 libraries.
Since then Motif has pretty much faded into the background and been replaced with newer widget toolkits, still built on top of X11, including Qt (1991-), wxWidgets (1992-) and GTK+ (1998-). These now run on many different platforms and bindings are available for many, many languages, including for their native C or C++.
These three free open source toolkits have been successful for the desktop application case but looking towards mobile and tablet platforms, these toolkits don't currently have the support there to take them into the future.
Qt
Native language: C++
Platforms: iOS (unofficial), Windows, Mac, Linux.
Probably the C++ based Qt widget toolkit is the most well established way of writing desktop cross platform applications. Smartphone support isn't really there yet, but there is an unofficial port to iOS. Linux's KDE desktop environment is written with the Qt toolkit. Many significant apps have been developed with Qt, including Autodesk Maya, VLC media player, Mathematica, Virtual Box and Skype. Qt is now owned by Nokia (although is still open source), and there was a release of a new version recently (Qt 4.8).
GTK+
Native language: C
Platforms: HTML5 (unofficial), Windows, Mac, Linux.
The C-based GTK+ widget toolkit is also a very well established way of writing cross platform desktop apps. Smartphone support isn't there, but there is an unofficial port to HTML5. GTK+ powers Chromium on Linux, the open source forerunner to Google's Chrome browser. The GNOME desktop environment is written with the GTK+ toolkit. The other notable app written with GTK+ is the one that launched the toolkit itself, GIMP, an open source bitmap image editor.
wxWidgets
Native language: C++
Platforms: iOS, Windows, Mac, Linux.
A C++ native mode toolkit that provides a thin abstraction to a platform's native widgets. It was originally developed as a desktop GUI toolkit in the same vein as GTK+ and Qt and support for iOS is still beta. There are a number of notable apps developed with wxWidgets including BitTorrent, Audacity, TortoiseCVS and RapidSVN.
Java and Silverlight
Sun's Java Swing UI Library (1997-) and Microsoft's Silverlight (2007-) were both attempts at "write once, run anywhere" (WORA) technology that provided a rich user interface library. Although technically successful, they failed in their attempt to become the ubiquitous technology that everyone uses to develop UIs. They both attempted to replace the 'native' look of apps developed on a particular platform and instead impose their own look and feel based on graphical primitives, which although being more powerful for developers, users on the whole didn't like.
As Johannes Fahrenkrug discusses here, people actually want to run Windows apps that look like Windows apps, and run MacOS apps that look like MacOS apps. To be fair, the Java Swing UI has actually undergone a lot of advances since it was first released and can now generate apps that do look perfectly native on all desktop platforms. The problem may be however that people's original experience of early Swing apps having a slow and inconsistent UI might have put them off using other Java apps and so contributed to its demise.
In the case of Microsoft's Silverlight and WPF, although not officially dead yet, they are now taking a back seat to newer technologies that were released by Microsoft at the September 2011 Build conference; Windows 8 allow developers to create new style 'Metro' applications by using either web technology (HTML5/JavaScript/CSS) or a traditional language - C#, VB.NET or C/C++ paired up with XAML for describing the UI. There's more detail about this topic on StackOverflow here for those interested.
The Rise of Web Applications and the App Store
The two big changes since the desktop UI toolkit days has been the rise of browser-based web applications and more recently the rise of downloadable apps running on smartphones and tablets such as Apple's iOS (powering the iPod touch, iPhone and iPad devices) along with Google's Android (powering a vast array of different smartphones and tablets from many hardware vendors). Google's recent Chrome OS also deserves a mention for creating an OS around the browser itself. These new class of devices offer a quick method of downloading, paying for and installing apps (often with just one click) and appear in the easy to use 'App Store' on iOS and 'Android Marketplace' on Android.
Microsoft is getting in on the App Store action a little late with its 'Windows Store' for Windows 8, which will be appearing some time in 2012. Its thought by Hal Berenson (a former Distinguished Engineer at Microsoft) that the upcoming Windows Phone 8 OS will be based on the same technology as Windows 8 and hence will unify the development platform for Microsoft's desktop, tablet and smartphone operating systems. This will likely be announced some time in 2012, probably at the same time Microsoft launches the 'Windows Store'. This will mean Windows 8's new 'Metro' style apps on the Windows Store will run on phones, desktops and tablets - something that neither Apple nor Google can lay claim to, just yet. Add in the possibility of an XBox update which adds support for running Metro apps, and you have a huge carrot which will make the unified Windows 8 platform very attractive to both application and game developers.
Choosing Your Platform - Desktop, Web or Mobile Application?
When choosing your platform, if you need full access the underlying file system, or access to hardware devices like serial ports, microphones, webcams, etc, then you may be better off staying with a desktop application. If you need platform independence on top of this then you can go with one of the traditional widget library technologies like wxWidgets, GTK+ or Qt to provide a full cross platform UI solution.
Alternatively, if you don't need so much access to hardware and can remain restricted to the browser, then HTML5 and JavaScript may be the way to go. Browser based web applications have their own set of problems however, including the browser incompatibilities, varying support for the HTML/CSS web standards and the Document Object Model (DOM). In addition, web application development generally makes it harder to create rich UI apps than for desktop or mobile applications. HTML5 will provide massive improvements, but web apps are still running in a browser and so will always remain sandboxed and limited in what they can achieve (no access to file system, serial ports, microphone, webcam, etc.).
The main advantage of the browser app however, and its a massive one, is that its everwhere and supported by every device, so if HTML5 takes off, then it could become the defacto standard for developing apps of any kind, desktop or not. As Jeff Atwood discusses in his seminal blog post All Programming is Web Programming; "the web is the most efficient, most pervasive, most immediate distribution network for software ever created - its almost completely frictionless". As Atwood mentions, more and more users gravitate towards preferring to run their apps inside the browser, on smartphones and on tablets where things 'just work' and there's generally nowhere near as much friction caused by the traditional desktop software setup and update process.
A third option available now is the cross platform mobile development SDK as detailed below (Mono, Appcelerator Titanium, Rhodes, PhoneGap, MoSync, Moai, Corona SDK and JUCE). Smartphone and tablet based applications are taking off, and these SDKs allow you to write once and run on any of these new class of devices, as well as in some cases also being able to run on the traditional desktop. These would seem to offer some of the 'power' of the desktop in terms of native code execution speed and access to hardware functionality, along with the enourmous 'frictionless' benefit that you get when publishing to an app store, where installing an app is literally a one click operation.
Mono
Native language: C#
Platforms: iOS, Android, Windows, Mac, Linux, Browser (e.g. via ASP.NET WebForms or MVC).
Cost: Windows, Mac & Linux: free. Android and iOS: from US$399 each. Free trial available.
License: LGPL/GPL/X11 combination. Commercial license available.
Source: Mono for Windows/Mac/Linux is open source. Mono for iOS/Android is closed source.
The C# based Mono cross platform library allows apps to be built using purely C#. However this is not strictly a cross platform UI library, since each supported platform has its own different set of Mono C# UI libaries, each with their own capabilities. The idea is that you build your software using the MVC (Model View Controller) pattern, so that the Model and Controller components (both written in C#) can be shared across all platforms without any changes. Only the View component needs to be re-written for each platform (again, in C#). Mono targets both mobile and desktop apps, however if you are just looking at developing a desktop application, then Mono probably isn't a big improvement over GTK+ or Qt, after all a well written C++ Library (with a Model and Controller component for example) will enjoy the same capability to be shared across more than one platform if you use Qt or GTK+ and then you wouldn't need a different UI library on each platform to create your view. There are several advantages that Mono has over Qt or GTK+ however - firstly in leveraging a team's existing knowledge (and codebase) of C# which is a popular language. Secondly, being able to target iOS, Android and the browser. Lastly, via Mono's .NET CLR implementation (Common Language Runtime), code is compiled into modules of bytecode, which are binary compatible across all the supported platforms.
There is also an open source library for Mono called MonoGame which lets you port with minimal effort XNA based games (which originally target the .NET platform and run only on Windows Mobile, Windows and XBox) to any of the Mono platforms such as MacOS, Linux, iOS and Android.
Appcelerator Titanium
Native language: JavaScript, Python and Ruby
Platforms: iOS, Android, Windows, Mac, Linux.
Cost: Community Edition is free. Indie Edition (extra APIs, help, support): US$499 per year.
License: Apache Public License v2
Source: Open source
An open-source solution which allows you to use web development languages (HTML, JavaScript, CSS, Python and Ruby) to build mobile and desktop apps. App data can be stored in the cloud or on the device, and apps can take full advantage of hardware, particularly camera and video camera capability. Appcelerator apps go through a complex compilation and optimization process which result in it creating apps that look, feel, and perform just like native apps, because you are using native UI components... so an iPhone app developed with Titanium will actually feel like an iPhone app. They also offer an API repository marketplace to buy and sell code to extend Titanium. One of the downloadable components allows you to develop your app using an MVC (Model View Controller) pattern. There is an active developer community Q&A site for Titanium developers which is similar in usage to StackOverflow.
Rhodes
Native language: Ruby
Platforms: iOS, Android, Windows Mobile, Blackberry.
Cost: Free
License: MIT License
Source: Open source
Rhodes is an open source, Ruby-based framework that allows the development of native apps for a wide range of smartphone devices and operating systems. The framework lets you write your code once and use it to quickly build apps for every major smartphone. Apps can take full advantage of available hardware, including GPS and camera, as well as location data. Rhodes enforces a strict MVC (Model View Controller) pattern on your apps. Views are written in HTML5 while Controllers and Models are written in Ruby.
PhoneGap
Native language: HTML5/JavaScript
Platforms: iOS, Android, Windows Mobile, Blackberry, Symbian, Palm.
Cost: Free
License: Apache License, Version 2.0
Source: Open source
PhoneGap is an open source framework that helps you develop apps for smartphones using web development languages such as JavaScript and HTML5. It also allows for access to hardware features including GPS/location data, accelerometer, camera, sound and more. PhoneGap lets you take a web app, run it in a UIWebView, and through javascript you can access iPhone features such as the camera an accelerometer. This means that it won't necessarily have the look and feel of a native app (like the other cross platform SDKs listed here). The idea is that you develop your web app like you normally do, and then use PhoneGap to 'bridge the gap' to the phone, and give you access to phone's hardware, that traditionally you couldn't access from a web-only app.
MoSync
Native language: C++
Platforms: iOS, Android, Windows Mobile, Blackberry, Symbian.
Cost: Free for Indie developers. From €199 (Euros) per year for Enterprise developers.
License: GPL v2. Commercial license available.
Source: Open source
The MoSync Mobile SDK is a cross-platform mobile application development SDK which allows the development of native apps. Free open-source, it is based on C++ but allows development also in HTML5 and JavaScript. MoSync provides access to a wide range of underlying device functionality, via a C++ SDK or optionally via JavaScript. It requires probably a greater degree of software skill from the developer, but in principle can enable a rich variety of different kinds of application.
Moai
Native language: Lua
Platforms: iOS, Android, Chrome Web Store, Windows, Mac, Linux.
Cost: Free
License: Common Public Attribution License Version 1.0 (CPAL)
Source: Open source
Although intended to be a mobile game development SDK, I think it deserves a mention here due to its unique scripted approach to cross platform development. Games developed with Moai run on iOS and Android as well as the Chrome Web Store, Windows, Mac and Linux. Designed to be programmed with the Lua scripting language, Moai is designed for experienced game developers who wish to use Lua for mobile development. The Moai framework itself is written in C++ and is intended to be called from the Lua scripting language, but can also be called from any other language supported by the host platform. The Lua script is run as interpreted byte code, but since very few Lua instructions are processed among all the input handling, this means that rendering, animation, collision detection, and physics math runs natively. Moai's physics engine for example is the Box2D open source C++ library. Moai is free and open source, however to build apps for iOS devices you'll need the iOS SDK and the Xcode IDE (presumably running on MacOS) and be a member of the Apple iOS developer program (US$99/year). To build apps for Android you'll need the Android SDK, the Eclipse IDE and an Android device.
Corona SDK
Native language: Lua
Platforms: iOS, Android, Kindle Fire, Nook Color.
Cost: US$199/year for Android. US$199/year for iOS. $349/year for all platforms. Free trial available.
License: Commercial, price as above.
Source: Closed source
A similar toolkit to Moai in that its primarily aimed at game developers, and apps are written with the Lua scripting language. Corona SDK was developed by two former Adobe mobile engineers and has been in development since 2007. It features a proprietary OpenGL-ES rendering engine, which allows for full hardware acceleration of graphics, including sprites that animate at full GPU speed. The Corona physics engine is built around Box2D as with Moai. Its free to try Corona and run your apps in a simulator on your desktop computer, but to build an app and publish it to an App Store, you'll need to pay a yearly subscription fee (of either US$199 per year for Android or iOS or the premium subscription of US$349 for all platforms). Your apps are built "in the cloud" on Corona's server. Note that if you are developing for iOS you'll still need to pay the yearly Apple iOS developer program fee which is currently US$99. There seems to be extensive documentation available for Corona and an active developer community forum. There has been a recent push to promote Corona for use not only for developing games but also for general apps and also interactive ebooks.
JUCE
Native language: C++
Platforms: Windows, MacOS, Linux, iOS, Android (Note that Android support is a work in progress).
Cost: Free for GPL license. Commercial license from £399 (UK pounds) per product.
License: GPL. Commercial license available.
Source: Open source
JUCE is an all-encompassing C++ class library for developing cross-platform software. Its designed to contain everything you're likely to need to create most applications, and is particularly well-suited for building highly-customised GUIs, and for handling graphics and sound. JUCE is developed by Raw Material Software and consists of a small team of developers based in London, England, founded by Julian Storer in 1999, who is still the primary developer today. It would probably be best suited to experienced C++ developers. Julian Storer himself is a professional C++ coder with over 15 years of C++ experience; he takes pride in the fact the source for JUCE is literate, coherent, cross-platform and high quality. Adding JUCE to your C++ application is very simple - the easiest way involves simply including juce.h in your files and adding a single .cpp file to your project. No need to compile any libraries or worry about dependencies.
Follow @dodgy_coder
Subscribe to posts via RSS
Sunday, November 27, 2011
"Yoda Conditions", "Pokémon Exception Handling" and other programming classics
Just reading through some of the excellent answers to this question posed on StackOverflow.com by John K
What programming terms have you coined that have taken off in your own circles (i.e. have heard others repeat it)? It might be within your own team, workplace or garnered greater popularity on the Internet.
Reposting some of the best ones below ...
Yoda Conditions
Using if(constant == variable) instead of if(variable == constant), like if(4 == foo).
Because it's like saying "if blue is the sky" or "if tall is the man".
by [zneak]
Originally, yoda conditions might have been introduced to reduce the potential of coding errors in the form if (5 = count) which would be picked up at compile time.
Pokémon Exception Handling
For when you just Gotta Catch 'Em All.
try
{
// do something
}
catch
{
// catch em all
}
by [woot4moo]
Egyptian brackets
The style of brackets where the opening brace goes on the end of the current line ...
if (a == b) {
printf("hello");
}
This style of brackets is used in Kernighan and Ritchie's book The C Programming Language, so it's known by many as K&R style.
by [computronium]
Refer to the Wikipedia entry on Indent style for further reading, including 1TBS (The One True Brace Style), Allman style (also known as ANSI style) and Whitesmiths style.
Different kinds of bug reports
Smug Report - a bug submitted by a user who thinks he knows a lot more about the system's design than he really does. Filled with irrelevant technical details and one or more suggestions (always wrong) about what he thinks is causing the problem and how we should fix it. by [aaronaught]
Drug Report - a report so utterly incomprehensible that whoever submitted it must have been smoking crack. The lesser version is a chug report, where the submitter is thought to have had one too many. by [aaronaught]
Shrug Report - a bug report with no error message or repro steps and only a vague description of the problem. Usually contains the phrase "doesn't work." by [aaronaught]
Thug Report - a bug submitted by one or more angry users, who then complain regularly until the bug eventually gets fixed." by [dodgy_coder]
Fermat's Last Post - a post to a bug tracker/email list/forum in which the author claims to have found a simple fix or workaround for a bug, but never says what it is and never shows up again to explain it (even after others have been puzzling over the bug for years). by [alan moore]
Floater - the case in a bug tracking system where a bug report remains "floating" at the top of the queue, but never gets assigned to a developer, maybe because there is a workaround in place.
Refuctoring
The process of taking a well-designed piece of code and, through a series of small, reversible changes, making it completely unmaintainable by anyone except yourself.
by [dan-vinton]
A play on the term Refactoring which was popularized by Martin Fowler in his book of the same name.
Stringly Typed
An implementation that needlessly relies on strings when programmer and refactor friendly options are available. For example, method parameters that take strings when other more appropriate types should be used. Excessively stringly typed code is usually a pain to understand and detonates at runtime with errors that the compiler would normally find.
by [mark-simpson]
A play on the term Strongly Typed, code which restricts the mixing of different or incompatible data types, allowing errors be picked up at compile time.
Different kinds of bugs
Heisenbug - a bug that disappears or alters its characteristics when an attempt is made to study it. by [jacob]
Higgs-Bugson - a hypothetical bug predicted to exist based on a small number of possibly related event log entries and vague anecdotal reports from users, but it is difficult (if not impossible) to reproduce on a dev machine because you don't really know if it's there, and if it is there what is causing it. To find these you will need to invest in a Large Hadron debugger. by [runrunraygun]
Hindenbug - a catastrophic data destroying bug - "Oh the humanity!". by [mike-robinson]
Counterbug - a bug you present when presented with a bug caused by the person presenting the bug. by [mike-robinson]
Bloombug - a bug that accidentally generates money. by [mike-robinson]
Schrödinbug - refers to a function/feature that appears to fluctuate between buggy and correct (like Schrödinger's cat, fluctuating between alive and dead), until somebody looks at the source code (opens the box), at which point it becomes permanently bugged. by [aaronaught]
Loch Ness Monster bug - a bug which cannot be reproduced or has only been sighted by one person. by [russau] (Also, Bugfoot is a great alternative).
UFO bug - a bug presented by customers, who, even when they're shown that it doesn't exist, will repeatedly report it again and again, believing it is real. by [Tuqui]
Mandelbug - a bug whose causes are so complex that its behavior appears chaotic or even non-deterministic. Named after fractal innovator Benoît Mandelbrot. by [coehlo]
Brown-paper-bag bug - a bug in a public software release that is so embarrassing that the author notionally wears a brown paper bag over his head for a while. by [ESR via Jargon File]
Sorcerer's apprentice mode bug - a bug in a protocol where, under some circumstances, the receipt of a message causes multiple messages to be sent, each of which, when received, triggers the same bug. by [ESR via Jargon File]
Mad girlfriend bug - a bug whose immediate effect remains hidden - the app outwardly seems to function normally and tells you that everything is fine. by [jeduan-cornejo]
Excalibur bug - when all of the developers within a company have tried to fix a particular bug but noneare worthy have succeeded, so far.
Load-bearing printf bug - when a line of debug output is required for the code to work - the code does not function if you remove it. by [Ken]
What programming terms have you coined that have taken off in your own circles (i.e. have heard others repeat it)? It might be within your own team, workplace or garnered greater popularity on the Internet.
Reposting some of the best ones below ...
Using if(constant == variable) instead of if(variable == constant), like if(4 == foo).
Because it's like saying "if blue is the sky" or "if tall is the man".
by [zneak]
Originally, yoda conditions might have been introduced to reduce the potential of coding errors in the form if (5 = count) which would be picked up at compile time.
For when you just Gotta Catch 'Em All.
try
{
// do something
}
catch
{
// catch em all
}
by [woot4moo]
The style of brackets where the opening brace goes on the end of the current line ...
if (a == b) {
printf("hello");
}
This style of brackets is used in Kernighan and Ritchie's book The C Programming Language, so it's known by many as K&R style.
by [computronium]
Refer to the Wikipedia entry on Indent style for further reading, including 1TBS (The One True Brace Style), Allman style (also known as ANSI style) and Whitesmiths style.
Different kinds of bug reports
Smug Report - a bug submitted by a user who thinks he knows a lot more about the system's design than he really does. Filled with irrelevant technical details and one or more suggestions (always wrong) about what he thinks is causing the problem and how we should fix it. by [aaronaught]
Drug Report - a report so utterly incomprehensible that whoever submitted it must have been smoking crack. The lesser version is a chug report, where the submitter is thought to have had one too many. by [aaronaught]
Shrug Report - a bug report with no error message or repro steps and only a vague description of the problem. Usually contains the phrase "doesn't work." by [aaronaught]
Thug Report - a bug submitted by one or more angry users, who then complain regularly until the bug eventually gets fixed." by [dodgy_coder]
Fermat's Last Post - a post to a bug tracker/email list/forum in which the author claims to have found a simple fix or workaround for a bug, but never says what it is and never shows up again to explain it (even after others have been puzzling over the bug for years). by [alan moore]
Floater - the case in a bug tracking system where a bug report remains "floating" at the top of the queue, but never gets assigned to a developer, maybe because there is a workaround in place.
Refuctoring
The process of taking a well-designed piece of code and, through a series of small, reversible changes, making it completely unmaintainable by anyone except yourself.
by [dan-vinton]
A play on the term Refactoring which was popularized by Martin Fowler in his book of the same name.
Stringly Typed
An implementation that needlessly relies on strings when programmer and refactor friendly options are available. For example, method parameters that take strings when other more appropriate types should be used. Excessively stringly typed code is usually a pain to understand and detonates at runtime with errors that the compiler would normally find.
by [mark-simpson]
A play on the term Strongly Typed, code which restricts the mixing of different or incompatible data types, allowing errors be picked up at compile time.
Different kinds of bugs
Heisenbug - a bug that disappears or alters its characteristics when an attempt is made to study it. by [jacob]
Higgs-Bugson - a hypothetical bug predicted to exist based on a small number of possibly related event log entries and vague anecdotal reports from users, but it is difficult (if not impossible) to reproduce on a dev machine because you don't really know if it's there, and if it is there what is causing it. To find these you will need to invest in a Large Hadron debugger. by [runrunraygun]
Hindenbug - a catastrophic data destroying bug - "Oh the humanity!". by [mike-robinson]
Counterbug - a bug you present when presented with a bug caused by the person presenting the bug. by [mike-robinson]
Bloombug - a bug that accidentally generates money. by [mike-robinson]
Schrödinbug - refers to a function/feature that appears to fluctuate between buggy and correct (like Schrödinger's cat, fluctuating between alive and dead), until somebody looks at the source code (opens the box), at which point it becomes permanently bugged. by [aaronaught]
Loch Ness Monster bug - a bug which cannot be reproduced or has only been sighted by one person. by [russau] (Also, Bugfoot is a great alternative).
UFO bug - a bug presented by customers, who, even when they're shown that it doesn't exist, will repeatedly report it again and again, believing it is real. by [Tuqui]
Mandelbug - a bug whose causes are so complex that its behavior appears chaotic or even non-deterministic. Named after fractal innovator Benoît Mandelbrot. by [coehlo]
Brown-paper-bag bug - a bug in a public software release that is so embarrassing that the author notionally wears a brown paper bag over his head for a while. by [ESR via Jargon File]
Sorcerer's apprentice mode bug - a bug in a protocol where, under some circumstances, the receipt of a message causes multiple messages to be sent, each of which, when received, triggers the same bug. by [ESR via Jargon File]
Mad girlfriend bug - a bug whose immediate effect remains hidden - the app outwardly seems to function normally and tells you that everything is fine. by [jeduan-cornejo]
Excalibur bug - when all of the developers within a company have tried to fix a particular bug but none
Load-bearing printf bug - when a line of debug output is required for the code to work - the code does not function if you remove it. by [Ken]
Irish surname bug - when a single quote in some user inputted data (typically a name field) causes some failure or crash downstream. Its usually because a single quote is a delimiter within SQL. Named after the common Irish surnames such as O'Leary or O'Malley. by [dodgy_coder]
Doctype Decoration
When web designers add a doctype declaration but don't bother to write valid markup.
by [zurahn]
New software features
A Unicorny - A feature that's so early in the planning stages that it might as well be imaginary.
A Barack Obama - A feature we'd really like to add to a project but will probably never get approval for.
by [jordan]
Different types of Code
Spaghetti Code - Code that's got one too many GOTOs, exceptions, threads, or other "unstructured" branching constructs. Program flow tends to look like a bowl of spaghetti - twisted and tangled.
Fear Driven Development
When project management adds more pressure (fires someone or something).
by [arnis-l]
Protoduction
A prototype that ends up in production.
by [chris-pebble]
Ninja Comments
Also known as invisible comments, secret comments, or no comments.
by [schar]
Smurf Naming Convention
When almost every class has the same prefix.
by [sal]
Veedubbing
To alter the algorithm of a software system for given known test inputs, or test conditions, to make the software appear to perform better than it really is.
[source][example]
Thanks again to the above answerers from the original StackOverflow question:
[zneak][woot4moo][computronium][aaronaught][dan-vinton][mark-simpson][jacob][runrunraygun][mike-robinson][russau][zurahn][jordan][john-d-cook][arnis-l] [nick-dandoulakis][chris-pebble][schar][sal][kelly-french][jeduan-cornejo]
And to the original poster of the question: John K
If you have any good suggestions, please add some comments below and I'll update the post.
Follow @dodgy_coder on Twitter
Doctype Decoration
When web designers add a doctype declaration but don't bother to write valid markup.
by [zurahn]
New software features
A Unicorny - A feature that's so early in the planning stages that it might as well be imaginary.
A Barack Obama - A feature we'd really like to add to a project but will probably never get approval for.
by [jordan]
Different types of Code
Spaghetti Code - Code that's got one too many GOTOs, exceptions, threads, or other "unstructured" branching constructs. Program flow tends to look like a bowl of spaghetti - twisted and tangled.
Spaghetti with Meatballs Code - An attempt at object-oriented code, but where the end result still remains dependent on some messy procedural (spaghetti) code.
Baklava Code - Code with too many layers. Also known as Lasagne Code. by [john-d-cook]
Ravioli Code - Object-oriented code consisting of a number of small and loosely-coupled software components.
Sausage Code - Once you've examined the code in detail ("how it's made") you'll never want to use it again.
Jenga Code - The whole thing collapses when you alter a block of code. Also known as Crispy Noodle Code.
Hydra Code - Code that cannot be fixed. One fix causes two new bugs. It should be rewritten. by [nick-dandoulakis]
Scar Tissue Code - Any code that is commented out but still included in the current and/or checked-in version. by [kelly-french]
Hooker Code - Code that is problematic and causes application instability (i.e. the application "goes down" often).
Pig's Lipstick Code - Code which has large amount of legacy and/or spaghetti code hidden via wrapper objects, so while it appears to new developers to be well designed, elegant, object-oriented code, when they start working on it in depth they realize just how ugly it really is.
Mortgage Code - Code purposely so terrible and complicated that only you can maintain it, forcing your employer to keep you, thus providing job security (so you can pay your mortgage).
Ghetto Code - A particularly inelegant and obviously suboptimal section of code that still meets the original requirements.
Swiss Army Code - Application code that is suffering from feature creep - it does a lot of things, but it does nothing well.
NP Tricky Code - An algorithm whose complexity is too hard for a mere mortal to figure out.
NP Hilarious Code - An algorithm whose complexity is "a joke", literally (as in BogoSort) or metaphorically.
Cut-and-waste Code - When someone cut and pasted code they found online (usually from a blog) into a production product; the result is usually a lot of wasted time trying to track down an obscure bug from code that undoubtedly made sense in the original context but not in our app. Also known as BDD - Blog Driven Development.
Neighborhood Bike Code - A module or a piece of code that every programmer at the company has touched.
Eraser Stains Code - Code that has been written, then re-factored multiple times leaving swaths of legacy code and design. Like erasing a sheet of paper so many times, the pencil marks are no longer the problem - the large greasy stain is.
Objectfuscated Code - Object-oriented code which has been abstracted to so many levels that no-one can understand it anymore.
Barnacle Code - Any piece of code (usually a static method) which has been appended to a class where it doesn't really belong, due to a lack of anywhere else to logically put it.
Autopilot Code - Code that was written by a programmer who was on 'auto-pilot' or wasn't really thinking about what they were doing.
Barnacle Code - Any piece of code (usually a static method) which has been appended to a class where it doesn't really belong, due to a lack of anywhere else to logically put it.
Autopilot Code - Code that was written by a programmer who was on 'auto-pilot' or wasn't really thinking about what they were doing.
Fear Driven Development
When project management adds more pressure (fires someone or something).
by [arnis-l]
Protoduction
A prototype that ends up in production.
by [chris-pebble]
Ninja Comments
Also known as invisible comments, secret comments, or no comments.
by [schar]
Smurf Naming Convention
When almost every class has the same prefix.
by [sal]
Veedubbing
To alter the algorithm of a software system for given known test inputs, or test conditions, to make the software appear to perform better than it really is.
[source][example]
Thanks again to the above answerers from the original StackOverflow question:
[zneak][woot4moo][computronium][aaronaught][dan-vinton][mark-simpson][jacob][runrunraygun][mike-robinson][russau][zurahn][jordan][john-d-cook][arnis-l] [nick-dandoulakis][chris-pebble][schar][sal][kelly-french][jeduan-cornejo]
And to the original poster of the question: John K
If you have any good suggestions, please add some comments below and I'll update the post.
Follow @dodgy_coder on Twitter
Sunday, November 13, 2011
Why do Programmers get paid less than PMs and BAs
I came across this interesting question over at programmers.stackexchange.com which asked: Given that programming is generally more difficult, why do business analysts and project managers get higher salary than programmers? What is it that makes their job a high paying job when even at most times programmers are the ones that go home late?
There were a few great answers, but only one stands out as the truth, and that is the one which is coming from an economic rationalist's viewpoint ...
Follow @dodgy_coder on Twitter
There were a few great answers, but only one stands out as the truth, and that is the one which is coming from an economic rationalist's viewpoint ...
People get paid less than their employers' "reservation price" (the most they would ever pay), and more than their "marginal product" (the least they would ever work for). Your actual pay on that spectrum is based on your bargaining power, relative to your employer.
Say your services to your company are worth $1000 a day. Under the gun, he would pay you that if he had no other choice. Say you would work for $100 a day if you had no other options. That's your range.
Say you're new and independent and unknown, and your boss is Google. Google has more bargaining power, because they can just wait and hire someone else, and lots of people want to work for them. You have less power, because you have to pay rent, so you'll get closer to $100 than $1000 a day.
Say you're the last COBOL programmer on Earth, and your boss's mainframe runs COBOL. Then you have more bargaining power, and will get closer to $1000 a day.
SO, either PM/BAs are worth more to the company, OR they have higher bargaining power. I don't think it's the first option, so must be the latter. Good people skills are rare. It's also hard to outsource them, as they have to meet clients. Their relative scarcity gives them more bargaining power, and thus higher pay.This is a great answer by NRM and although slightly boring compared to the other answers which touch on the political side of things, it definitely has the ring of truth to it. As he mentions, good people skills are rare, and provide a huge benefit in any job, especially in the field of software development.
Follow @dodgy_coder on Twitter
Sunday, November 6, 2011
StackOverflow's Programming Language Bias
Using StackOverflow.com, I've always had the impression that its biased towards C#, and .NET in general. That might have been because on the SO tags page C# is number one, with the most questions tagged, or maybe because much of the site itself is built with C# and MVC.NET. So I thought it would be interesting to compare the rankings of the tag popularity on StackOverflow with a leading language popularity index (the TIOBE index).
Method
The "Stack Overflow Representation" represents a ratio of the SO tag count (as a percent of total questions) divided by the TIOBE language index percent. Where a representation of 100% means that the SO tag count is aligned exactly with the TIOBE language index. An "over-representation", greater than 100%, might mean there's a greater number of questions on SO than we'd expect. An "under-representation", lower than 100%, might mean there's not as many questions on SO than we'd expect.
Results
Suprisingly, JavaScript came out to be the most "over-represented" language on SO, by quite a long way at 294%. Could this also be because programming JavaScript is generally quite difficult and will result in people seeking help more often? Following this was C# (which I had expected to be number 1), at 153%. After this, PHP, Ruby and Python were basically fairly balanced at around 100%. The most "under-represented" major language would definitely be C at 11%. Three other major languages which seemed to be a bit under-represented, below 50%, were C++, Java and Objective-C.
Data Sources:
Method
The "Stack Overflow Representation" represents a ratio of the SO tag count (as a percent of total questions) divided by the TIOBE language index percent. Where a representation of 100% means that the SO tag count is aligned exactly with the TIOBE language index. An "over-representation", greater than 100%, might mean there's a greater number of questions on SO than we'd expect. An "under-representation", lower than 100%, might mean there's not as many questions on SO than we'd expect.
Results
Suprisingly, JavaScript came out to be the most "over-represented" language on SO, by quite a long way at 294%. Could this also be because programming JavaScript is generally quite difficult and will result in people seeking help more often? Following this was C# (which I had expected to be number 1), at 153%. After this, PHP, Ruby and Python were basically fairly balanced at around 100%. The most "under-represented" major language would definitely be C at 11%. Three other major languages which seemed to be a bit under-represented, below 50%, were C++, Java and Objective-C.
Data Sources:
- Stack Overflow data taken from: StackOverflow.com/tags - data snapshot taken at 2:50am UTC, 6-Nov-2011. Total tag count was 2,254,639.
- TIOBE data taken from: latest available (October 2011) at www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Saturday, October 1, 2011
How to Become a Better Programmer
Here then, in no particular order, are twelve positive things that you can do, at any point in your career, to improve your programming skills. These will also have the added benefit of injecting additional passion into your programming ...
1. Never Stop Learning and Reading
Consciously try to improve yourself and the quality of code you write. Think about what you're doing, why you're doing it, and how you can do it better. Look back at what you've done on previous projects, and how you might do it differently now, or where you could still improve on it.
2. Work With People Smarter Than Yourself
Working with smarter and/or more experienced developers will teach you a great deal. You can learn a lot by reading their code, watching their practices and listening to their opinions and stories. Also, you should always listen to what others have to say, regardless of whether they're junior, intermediate, senior or guru-level developers.
3. Become a Polymath (or 'Jack-of-all-Trades')
Decide to be a 'Jack-of-all-Trades' - also known as a Polymath, Polyglot, Generalist, Renaissance Man or Multi-specialist. This will allow you to avoid becoming 'pigeon-holed' into one specialty, which can stagnate your programming skills, as well as hurt your future employment prospects if your 'specialty' suddenly becomes yesterday's technology. Something to keep in mind is 'the half-life of knowledge' law of technology; it tracks with Moore's Law: half of everything you know will be obsolete in 18-24 months. An expert who chooses the wrong discipline can easily be undermined by the press of technology; a generalist only has to add some more skills and remember the lessons of the past in applying those skills.
4. Read and Document Other People's Code
Read and attempt to understand code written by others. Plus, write documentation for code written by other people. Writing code is significantly easier than reading someone else's code and figuring out what it does. You can see how they do something - maybe they do it in a better way than you. And sometimes this can be one of the best ways to learn how not to do something.
5. Get Programming Experience on a Real Project
There is nothing like getting in and coding, especially under pressure - work on a real project, with real fickle customers, with real, ever-changing requirements and with real engineering problems.
6. Teach Others About Programming
Take a part-time job tutoring computer science students at a local university or college. This will force you to understand something at a completely different level, since you have to explain it to someone else. As Douglas Adams wrote, "the best way is to try and explain it to someone else. That forces you to sort it out in your mind. And the more slow and dim-witted your pupil, the more you have to break things down into more and more simple ideas."
7. Learn One New Programming Language Every Year
One year gives you enough time to get past the basics - it pushes you towards understanding what's beneficial in that language, and to be able to program in a style native to that language. Each language will change the way you think about programming, and how they do things, to compare that to what you already know.
8. Complete One New Pet Project Every Year
Start a "pet" project and follow it to completion and delivery. A good pet project will push your boundaries and keep you interested; it may be something you have experience with and enjoy plus something you don't know about. E.g. if you know something about game development but don't know Ruby, a good pet project may be to develop a game written in Ruby.
9. Learn Assembly Language
Learning a low level language like assembly gives you insight into the way computers 'think' without any high-level abstractions; the elegance at this level is surprising. There are no wasted motions, no disposing of data, and bugs can have a far greater impact. Developing at this level will teach you efficiency and hone your critical thinking and logic skills.
10. See Your Application From the End User's Perspective
Step out of the echo chamber and improve your understanding of the end-user aspect of software development. Interact with the end-user to see, through their eyes, how they use your software. End users are typically not technical, and they often see software as a magical piece of work, while you see software as a logical set of steps. The two worlds are completely different - what seems easy and logical to you may seem cryptic and inscrutable to others. You can also find out what kind of 'abhorrent' information they throw at your application. This will help you generate good test cases and stop assuming your program will always be fed the correct set of data.
11. Start a Physical Exercise Program
You work a whole lot better when you're in good physical shape - problems become easier and less overwhelming, wasting time is much less of a temptation, you can think clearer, and working through things step by step doesn't seem an arduous task. An old one but here it is: "Sound body, sound mind.". Regularly devote a bit of time to physical exercise - riding a bike, walking, running, swimming, whatever suits you best.
12. Learn Touch Typing
Typing for a programmer is essential. Everyone has had a coworker who typed using just two fingers and had to look at the keyboard for everything before pecking out their code one letter at a time! Learning to touch type is a quick and effective way to give your productivity a boost as a programmer.
Follow @dodgy_coder
Subscribe to posts via RSS
1. Never Stop Learning and Reading
Consciously try to improve yourself and the quality of code you write. Think about what you're doing, why you're doing it, and how you can do it better. Look back at what you've done on previous projects, and how you might do it differently now, or where you could still improve on it.
- Read books, not just websites.
- Read for self-improvement, not just for the latest project.
- Read about improving your trade, not just about the latest technology.
2. Work With People Smarter Than Yourself
Working with smarter and/or more experienced developers will teach you a great deal. You can learn a lot by reading their code, watching their practices and listening to their opinions and stories. Also, you should always listen to what others have to say, regardless of whether they're junior, intermediate, senior or guru-level developers.
3. Become a Polymath (or 'Jack-of-all-Trades')
Decide to be a 'Jack-of-all-Trades' - also known as a Polymath, Polyglot, Generalist, Renaissance Man or Multi-specialist. This will allow you to avoid becoming 'pigeon-holed' into one specialty, which can stagnate your programming skills, as well as hurt your future employment prospects if your 'specialty' suddenly becomes yesterday's technology. Something to keep in mind is 'the half-life of knowledge' law of technology; it tracks with Moore's Law: half of everything you know will be obsolete in 18-24 months. An expert who chooses the wrong discipline can easily be undermined by the press of technology; a generalist only has to add some more skills and remember the lessons of the past in applying those skills.
4. Read and Document Other People's Code
Read and attempt to understand code written by others. Plus, write documentation for code written by other people. Writing code is significantly easier than reading someone else's code and figuring out what it does. You can see how they do something - maybe they do it in a better way than you. And sometimes this can be one of the best ways to learn how not to do something.
5. Get Programming Experience on a Real Project
There is nothing like getting in and coding, especially under pressure - work on a real project, with real fickle customers, with real, ever-changing requirements and with real engineering problems.
6. Teach Others About Programming
Take a part-time job tutoring computer science students at a local university or college. This will force you to understand something at a completely different level, since you have to explain it to someone else. As Douglas Adams wrote, "the best way is to try and explain it to someone else. That forces you to sort it out in your mind. And the more slow and dim-witted your pupil, the more you have to break things down into more and more simple ideas."
7. Learn One New Programming Language Every Year
One year gives you enough time to get past the basics - it pushes you towards understanding what's beneficial in that language, and to be able to program in a style native to that language. Each language will change the way you think about programming, and how they do things, to compare that to what you already know.
8. Complete One New Pet Project Every Year
Start a "pet" project and follow it to completion and delivery. A good pet project will push your boundaries and keep you interested; it may be something you have experience with and enjoy plus something you don't know about. E.g. if you know something about game development but don't know Ruby, a good pet project may be to develop a game written in Ruby.
9. Learn Assembly Language
Learning a low level language like assembly gives you insight into the way computers 'think' without any high-level abstractions; the elegance at this level is surprising. There are no wasted motions, no disposing of data, and bugs can have a far greater impact. Developing at this level will teach you efficiency and hone your critical thinking and logic skills.
10. See Your Application From the End User's Perspective
Step out of the echo chamber and improve your understanding of the end-user aspect of software development. Interact with the end-user to see, through their eyes, how they use your software. End users are typically not technical, and they often see software as a magical piece of work, while you see software as a logical set of steps. The two worlds are completely different - what seems easy and logical to you may seem cryptic and inscrutable to others. You can also find out what kind of 'abhorrent' information they throw at your application. This will help you generate good test cases and stop assuming your program will always be fed the correct set of data.
11. Start a Physical Exercise Program
You work a whole lot better when you're in good physical shape - problems become easier and less overwhelming, wasting time is much less of a temptation, you can think clearer, and working through things step by step doesn't seem an arduous task. An old one but here it is: "Sound body, sound mind.". Regularly devote a bit of time to physical exercise - riding a bike, walking, running, swimming, whatever suits you best.
12. Learn Touch Typing
Typing for a programmer is essential. Everyone has had a coworker who typed using just two fingers and had to look at the keyboard for everything before pecking out their code one letter at a time! Learning to touch type is a quick and effective way to give your productivity a boost as a programmer.
Follow @dodgy_coder
Subscribe to posts via RSS
Subscribe to:
Posts (Atom)