My Answer To: I want to learn programming, should I attend a code school?

I recently had a reader ask me if they should attend a coding academy because they want to get into programming. Here is my answer:

There are many success stories involving code schools. In fact my grandmother was one of those success stories, but more about her later. Still, I’d be careful of code boot camps, code schools, hack schools, code academies and the like. Read the reviews and talk to grads who are a year or so ahead of you.  One code school in my home town recently shut down suddenly with no warning. Anecdotally, I’ve heard of code schools hiring their own grads as tutors or instructors just so they can claim a high percentage of their grads are employed in the field. At best that is called academic inbreeding, at worst it is a pyramid scheme. Aside from avoiding getting ripped off, you want to make sure of the quality of the curriculum. These schools often jump directly to frameworks and web development without providing proper fundamentals like what is a function, what is a variable, etc.

So yes, this equation is sometimes true:

$12k Code camp + $2k Mac Book Pro = Job in software @ $60-110k/yr

but this makes more sense:

The Knack + Enjoyment = A career you love that pays well

Software takes a special knack and to be good you must love it:

To succeed in software you need many things, but at the top of my list is an innate knack and natural enjoyment for it. I’d rule those out first before dropping money on tuition.

My first criteria is you must have the gift for coding, and that is probably genetic. What goes into the innate ability to code has been studied and blogged about. The bottom line is, there is no way to teach everyone to write code. It doesn’t work the in same way that almost all of us absorb language as infants or grow up and join Facebook if we want.

My second criteria is you must enjoy writing code. Know anybody who can concentrate on abstract details for long periods of time? A lot of people I know can’t believe I sit in a room for 10-12 hours a day doing what I do. They say it would drive them totally nuts. Even very gifted and intelligent people struggle and end up hating it. I once had a calculus teacher who despised writing code. He couldn’t get his program to run, even though he said it was mathematically perfect… It was probably just a syntax error.

How many people have ‘The Knack’ as a percentage of the population?

The short answer is somewhere between 1.5% and 3%, but the numbers are pretty fuzzy.

theknack

Based on the bureau of labor statistics, in 2014 in the US there were 2.3M jobs directly related to writing code. According to this infographic of the 17M people in the ‘nerd economy’ world wide, 44% were in the US. That is ~7.5M but may include some non-programmers. Let’s take a guess and say in the US it is 5M. Out of population of roughly 320M in the US, that comes out to ~1.5% of people who write code for a living.

If you walk past the average family on the street, you would see 1.8 children. If you walk past 100 people on the street, 1.5 of them would be employed in software development. Except in the bay area it would probably be closer to 50! The 1.5% estimate only reflects those who are active, not those who have the knack + enjoyment but do something else, nor those who were downsized. As a planet we can get that number higher if age bias goes away and more opportunity is provided for minorities, women, and people of low socioeconomic status.

What goes into ‘The Knack’ for writing code?

The following traits appear to be closely associated with coders:

  • Analytical skills
  • Problem solving
  • Rapid comprehension (fast learner)
  • Mathematical aptitude
  • Musical proficiency
  • More interest in truth than appearances
  • Good memory
  • Creativity
  • Do-It-Yourself (DIY) hobbies
  • Obsession with science fiction
  • T-shirt collections
  • Difficulty picking good looking color combinations

 

Software is a journey, it is cyclical, and the learning never stops:

The idea that anybody with $12k can become a great programmer in a matter of 5 months is so wrong. I’ve been programming for almost 20 years and I’m still improving. Who you work with and what you are working on matters. It may take a decade for everything to really start clicking.

We live in a golden age of technology expansion. Right now the world is experiencing another technology bubble. This one may not be as big or as violent as the dot com boom, but programmer demand is out of control. Overall I think demand for software will continue to grow for many years while being bridled by bust and boom business cycles. That is until self aware artificial intelligence gets loose and kills us all (software developers first no doubt).

I recall during the dot com boom my wages were artificially boosted which I thought was permanent at the time. I also found myself working around a bunch of yahoo’s who had no business in software. They were ultimately weeded out of the field. That pattern is peaking yet again.

A CS degree, or some kind of complimentary degree from an accredited university should be on your road map. To test the waters you might start with a free online course.

In software it is entirely possible to start off being self taught – like I was. My first paying gig was at age 16. I was literally the kid down the street. At the time I was very rough around the edges. Side projects and eventual part time employment allowed me to pay my own way through college. It was hard, I clocked 20-30 hours per week and took 8-16 credits per term including summers. I got into the habit of running through flash cards every night before I went to bed. Side note – it turns out memories are best formed right before going to sleep, so studying before going to bed helps with retention. What I learned in college wasn’t as immediately valuable as my software skills, but it ended up being the prefect compliment to my life. I learned how to write, how to analyze information, and grow up some. I also met my wife in college.

Your assignment:

To find out if software is the life for you, my advice is to get a cheap PC laptop, install linux on it (Ubuntu or RedHat), and start with (Python, Ruby or PHP), Javascript, and SQL. Online outlet stores like the Dell outlet  and the Lenovo outlet have good deals on refurbished hardware (which is basically an extended burn in test).

Start going to local meetups and hack nights. Get in the habit of learning all the time. Whenever you see a word or acronym you don’t know, google it and make a flashcard for it. Flip through video presentations from past software conferences like OSCON, InfoQ, etc, much of the content is made available for free!

Check out some books on programming from the library. The web is great for bits and pieces, but a published book typically has more depth.  The first chapter of most programming books will be about setting up your computer and installing the right programs (called your environment). Then you will write a program that prints ‘hello world’ on the screen. Note how you feel and how smoothly it went. If you are totally flummoxed this, you may need to some face to face help, which brings me to the next section.

Get a mentor:

There are many people out there willing to share their knowledge. Some will charge anywhere from $10-$100/hr, others ask nothing in return, and some work for pizza. Mentoring is something I plan to do for the rest of my life, especially in my twilight years to keep my mind healthy and to give back.

I wish I would have had more mentoring earlier in my career. My bosses were gracious enough to introduce me to a few senior people. I met with them every few months and emailed more often. I should have taken more advantage though!

It was a simpler world back then. There were fewer frameworks and languages vying for attention. In today’s work the ‘stack’ or the ‘tree’ of technology is really getting out of hand with dozens of options in each category. Talk through this with your mentor.

Some encouragement:

Anybody can get into the field of software, not just white guys like me. In the 1970’s my grandmother took a programming course, perhaps similar to today’s boot camps. She started on punch cards and later wrote Cobol for the IBM mainframe. They tried to bring her back out of retirement in the late 90’s to help fix Y2k bugs but she wisely declined. I suppose I got the knack from her. As a female, she was a pioneer in the tech industry. I’m really proud of her. Her department had a few female coders. I’ve always noticed companies hold onto their female coders. There is a huge movement out there to get more women and minorities in tech. I fully support that kind of thinking. Yes, at bad companies there is a glass ceiling, harassment, and the old boys club to put up with. Screw those kinds of places. Be like Grandma and go for it.

Posted in Code, For New Developers | Tagged , , , | Comments Off on My Answer To: I want to learn programming, should I attend a code school?

Three Failings of Scrum and the Old School Solution

Everywhere I look I see software rapidly falling into obsolescence that will need to be re-written soon. A good example is how rapidly JavaScript (ECMAscript) is evolving. In a few years nobody will get excited about maintaining a ECMA5 code base… this is already true for some early Angular 1.x apps, am I right??? Another driver of obsolescence is the continual force march of updates and upgrades from big corporations like Microsoft, Apple and Oracle. In that case, it is all about money. It recently dawned on me that Scrum is also a driver of early obsolescence! In a nutshell, Scrum leads to technical debt and conceptual debt, but it can be managed if a) you can take a medium to long, view technology wise, and b) you have a healthy level of skepticism about anything that is hyped up.

Call me crazy, but I think software should last more than 2-5 years. There is a LOT of old software out there that needs maintenance. Some of it is built really well and stands up to the test of time (abstraction, configuration, logging, not locked into a particular vendor, etc). However, a percentage of that software starts off as or morphs into a totally unmaintainable rats nest. I’m talking about the kind of spaghetti that makes developers run and hide. Low quality software leads directly to higher costs and expensive fires like data breaches and glitches that release prisoners early. CEO’s hate having to deal with technology risk, because they think they can’t control it. I’ll explain below why Scrum feeds into this problem.

An overview of Scrum:

Scrum is a development methodology, a way of organizing work on a software project. The most commonly implemented idea in Scrum is a daily stand-up, where all team members gather together for a quick status report. Each team member lists what they did yesterday, what they will do today, and anything they are stuck on.  Work is broken up into time boxed segments called sprints (usually 1-2 weeks long).  To the team, the current sprint is all that matters. Each sprint has to produce something of value to the end user, so it can’t be all UML diagrams and refactoring.  What gets worked on during the sprint is selected by the product owner, via a backlog of tasks they have ranked in order of importance to them. These tasks should already have estimates associated with them. Ideally, those estimates were reviewed by two or more technical people who are actually doing the work.  The unit of effort can be hours, or more abstract things like story points, or even bananas.

What, estimating in bananas??? It sounds nuts, but it gets into the fact that estimates are often misconstrued, wrong, and used as political footballs in the game that is middle management. When you say 8 hours, what does that really mean? Is it 8 ideal hours? Is it one work day with room for meetings and water cooler sessions? Does it mean the work will be ‘done’ tomorrow? When an estimate is first uttered, it magically turns to stone and becomes a commitment to those who heard it. They may try to talk it down which causes the stone to shrink, again magically.  Estimates are rarely changed unless extraordinary information comes to light. At the end of the day, as a middle manager, with bananas you have more leeway (if your boss will still take you seriously). A login page might take 4 bananas, but that upgrade to the reporting module might be 40 bananas. How many hours is a banana is worth? In Scrum, that is determined by looking at past sprints. Measure how many bananas got done vs how many person hours were available on the team that sprint. To tell how much ‘work’ you can get done each sprint, compare estimated bananas vs actual completed bananas, adjusted for variations in team size. That figure is called velocity. A team’s velocity might be 100 bananas or 1000. The actual number doesn’t really matter.

There is an ongoing circular debate about how to solve the estimation problem. Topics include relative vs absolute estimates, the estimation process, the units to use in estimation, who should do the estimating, estimate poker sessions, etc. Estimates by nature are probably wrong, so why fuss about them so much? Have the person doing the work make the estimate and then get out of their way. I’ve never seen actual work get done while philosophizing about estimates.

Speaking of philosophy, here is a better question to ponder: what is your team’s definition of done? Does it include writing some documentation? Unit tests? Peer review? QA testing? Deployment? Don’t forget those very important aspects of software development in your estimates. Skip these and somebody will be disappointed later on. The strategy most immature companies use is to entice their staff to becomes heroes which makes things even worse later on. They say it takes a start-up about 2 years to paint itself into the corner…

I’ve also found a) tasks have a funny way of getting completed within their estimates (but to varying degrees of quality and done-ness), b) it can be much faster to just do the task rather than sit around estimating.

To be fair, some estimating is a necessary part of the planning phase of any project. No approach is perfect. It is wise to double or triple estimates to allow padding and get the job done right. You only know how long it actually took until after the work is done. This bothers middle managers who need to file reports to their bosses showing how efficient and frankly amazing they are at herding cats and seeing into the future. To cover up that huge gap in managerial control, the Scrum people invented banana velocity to explain what is going on in a quasi-economic sense. I suppose banana velocity sounds sufficiently geeky so non-technical people just accept it. In repressive office settings dominated by cubicles, bananas go by the term ‘story-points’ which sounds more official, but not concrete enough to be an hour or a dollar which still leaves the all important leeway.

Scrum’s Strengths:

As a developer, I enjoy working in a Scrum environment because of the balance it strikes between structure and being left alone to work.  Agile software development and its offspring Scrum and Kanban, achieve balance by making the software development process flexible. Work is based on real goals. Output is measurable. Features are launched regularly, sometimes with quick turn around. Scrum’s iterative releases are especially satisfying for the team.   The stand-ups keep everyone in sync and problems are surfaced right away. Communication between technical and non-technical stake holders is baked into the process!

On a green field system, where the code is new, Scrum is fantastic because you can fly though features and put things in the hands of customers quickly. For one off contractor style projects Scrum does a great job.

Where Scrum falls apart:

Developers enjoy Scrum because they are left alone to work, but that enjoyment is a form of moral hazard. As a wise master put it: ‘the untroubled ease of programming beneath [Scrum’s] sheltering branches‘ (see The Tao of Programming section 7.1). Moral hazard is when one party is insulated from risk (in this case, the happy programmer), and they behave in a way they enjoy that may cause another party to suffer a loss (in this case the business they work for). A happy developer, working on small tasks week by week, does not see or have reason to care about the big picture. With Scrum, the big picture takes a back seat to the prioritized tasks on the backlog. The lack of big picture thinking and focus on the short term is what makes Scrum so dangerous to software quality.

As the sprints wear on, things begin to change. The velocity begins to drop and estimates begin to creep up, but that’s okay because we are talking bananas and there is room to fudge it. Eventually weaknesses begin appearing in the system design and a few fires break out. Perhaps a scapegoat will be blamed for the headaches? It is the system, not the people that is causing the actual problem.

There are three main ways in which Scrum causes the code base to be more expensive to maintain as it progresses, which leads to obsolescence.

1) Scrum is like playing drunk jenga in reverse:

Scrum says nothing of technical details, leaving that ‘to you’, as in, an exercise you can do on your own. Seriously, unless we are talking about homework assignments, nobody does those. Given the lack of specific direction there, and the fact the Scrum product owner in a purely technical sense is likely clueless, I don’t think most Scrum teams address technical details as good as they could, or at all. The new bits continually accumulate on top of the older bits forming a kind of upside-down pyramid that is prone to collapse. Imagine building a 2000 square foot house, where every two weeks living space has to be delivered to the customer. Every two weeks the customer immediately moves into the new living space. For the next sprint, you either start with a small room and build a larger story on top, or plop down a new disjointed foundation and knock holes in the walls to join the rooms. Even with a blueprint the decisions made in the early sprints invariably end up being poor decisions later on.

2) Non-technical product owner steers the ship:

At the start of each sprint, called the sprint planning meeting, there is a little dance that happens between the technical and non-technical staff as to how much customer facing work gets done vs how many backend fixes and improvements are made during the sprint. The product owner controls the money, so they get what they want. Unfortunately, the product owner may not understand technical jargon or care that the RAID array needs its drives updated. System improvements and maintenance tasks usually get pushed to the next sprint until they manifest themselves as a fire which interrupts the sprint and defeats the process. I like to call that spontaneous self combusting technical debt. When that happens, sometimes it is a random surprise, but it is often due to poor management. Scrum seems to bring out the worst decisions in non-technical managers.

Over the life of the software system, Scrum is sort of like driving with a blind fold on.  Sure the first few blocks might be okay, but you’ll be in the ditch a mile or so down the road. I’ve seen this unfold many times. A non-technical product owner (someone who I often respect and work well with) ignores the overall technical health of the system for a short term gain (need to get paid, need to make client X happy ASAP, etc). On a lot of software projects, especially under Scrum, the non-technical leadership has too much sway on technical matters. They may not trust technical people, they may want to assert their dominance, or they may be blindly following Scrum to the letter. Either way, we need a methodology that tells non-technical leaders to listen, but that hasn’t been invented yet. Only a few are smart enough to listen and lead. I’m not saying each sprint should be 100% ruled by geeks. That is just silly since technical people often have no clue about business. It needs to be a healthy balance, and I’ll get to that later.

Related to estimation and non-technical product owners, consider an example.  Let’s say the backlog has twenty tasks each taking 10 bananas (200 bananas total) and at the very bottom some technical task estimated at 100 bananas that refactors the system making everything else easier. The 100 banana task delivers nothing to the customer, but reduces the effort of the ten banana tasks to just one banana. The net cost of everything is 120 bananas, but requires halting new deliverables for 100 bananas worth of work.

I’ve observed that tasks with smaller estimates are universally made higher priority. This is the – let’s get the cheap stuff done first school of thought.  I have rarely seen a non-technical product owner opt for the 100 banana task even though the payoff is clearly there. With Scrum, the product owner gets hooked on immediate results from each sprint. They are turned off from devoting two or three entire sprints to something ‘big’ and ‘risky’. Thus, the big important technical stuff never gets done. This leads to problems and the technology gets blamed instead of the real culprit – the process and people managing the technology.

3) Commoditization of developers:

Others have pondered, Is Scurm is the McDonald’s of software development? Comparing any software development process to McDonald’s is a bit rough. Though it is true, Scrum views developers the same way McDonald’s views burger flippers. Scrum treats developers as interchangeable resources capable of producing bananas.

Career-wise, under Scrum, developers rarely get a chance to do big picture thinking beyond the current sprint. The backlog, which is prioritized by the product owner, dictates the engineering effort each sprint. No work is supposed to span multiple sprints. There is a limit to career growth that can happen in this setting. The post Why Agile and especially Scrum are terrible goes into more detail on that subject. It hypotheses that some companies use Scrum to turn low wage C players into more than the sum of their parts. Bizarrely, this may be seen as a ‘profit’ for the company using that strategy.  In reality the best people in software either find a culture they fit with, program in comfort under the shade of the corporate tree branches (and could give a shit about banana velocity), or they create their own companies.

How to use Scrum correctly:

So, what can we do about the fact that Scrum leads to problems down the road? In the software world, as usual, the answers lie in The Mythical Man Month, which was originally published in 1975, way before Agile was a thing (roots in the mid 80’s at the earliest).

In software, there are three main wheels turning: the business, the architect/designer, and the implementer (aka coder). Scrum places the business in control of the implementer and kills the architect. This problem can be remedied with the following:

To address weakness #2 Non-technical product owner steers the ship:

a) Get a product owner who understands the business AND the technology.

or

b) The product owner is replaced by a committee made up equally of business types and technology types who prioritize the back log on a regular basis.

To address weaknesses #1 drunk jenga design and #3 commoditization of developers:

The architect/designer skill needs to be resurrected and given prominence. Work will still be broken into sprints, but that work must adhere to the big picture technology-wise. In other words, there is a plan in place, a road map that lives outside whatever happened to bubble up to the top of the backlog this week. That plan should influence what bubbles to the top of the backlog.

This role could be filled by a lead or senior dev. It should involve junior devs on a rotating basis to give them a career boost and learning opportunities.

The Mythical Man Month advocates for an empowered designer. In reality, many software architects are powerless ‘technical leaders’, spouting off Power Point email attachments in excess of 10MB. Software developers are largely free to ignore all the white tower bullshytt. If the software architect has no teeth, you might as well just laugh behind their back with everyone else. They gave up their coding skills for Power Point anyway, didn’t they?

To ensure quality and consistency, many open source projects nominate a benevolent dictator for life – BDFL. Hey, if you want to get big things done, history has shown a dictatorship is the way to go. The people’s feelings be damned! The BDFL makes decisions that sometimes screw over a few small groups, but they are working towards the greater good for the project.

All Scrum projects would benefit from a technically oriented benevolent dictator (not necessarily for life). This role is not the Scrum master. This person must understand the business. They must also be insulated from petty politics and short-term incentives. The equivalent might be giving the CTO a 25% stake in the company, and starting with the understanding that sometimes the business won’t get what they want right away. The business side needs to trust the CTO’s judgment implicitly like Kirk trusted Spock.

Posted in Application Development, Business, Code, Work | Tagged , , , | 2 Comments

Is localhost development obsolete?

Topic explored: Someday soon developers will only need a basic Chrome Book and a wifi connection to do their work. No software will be installed locally other than a browser.

I’m not so sure this trend will pan out across the board, but there are several reasons it makes sense.

Software development traditionally requires a high end machine capable of running everything the server needs plus an array of development tools. That translates to a non-trivial setup process and leads to subtle variations in what packages are installed. Some languages try to make life easier, for example python with virtualenv, or Ruby with rmv, but it is rarely a 100% perfect match between all team members and the production servers.

Why is localhost bad?

Using the exact same system libraries in dev, qa, staging and production is a smart thing to do because it eliminates bugs related to differences between versions. As a contract developer with multiple clients, I often have several projects going at once on the same development laptop. Keeping all the dependencies wired correctly gets annoying sometimes, but I’ve kept good notes and for the most part it doesn’t get in the way.

Dependency hell is a real place and I’ve been down there too many times.

In the modern world we solve problems by outsouring them to the cloud. So why not outsource localhost to the cloud?

The winning combination as I see it is:

  • Web Shell for Vagrant / Git
  • GitHub (or BitBucket) for collaboration
  • Web based IDE
  • Slack – not required but might as well publicly get on the Slack bandwagon now, ’cause it does make my life better.

In a nutshell, this new solution allows developers to edit code in a browser tab, click a button to launch a vagrant instance on AWS,  access shell commands in another browser tab, and integrate perfectly with source control. No need for any development libraries or tools installed locally. This lends itself heavily to the LAMP / MEAN stacks, but I don’t see why Java, C++, or any platform wouldn’t work with this approach.

Vagrant makes localhost as a server obsolete:

vagrant

Vagrant is a utility for spinning up virtual machines that run your application. Vagrant is heavily configurable. The config file lives in your project’s source code, typically in the root directory. With Vagrant all team members run the exact same virtual environment. Vagrant integrates with VirtualBox by default, but also Amazon Web Services, VMWare, and allows custom providers. Vagrant links your source code into the app directory it is hosting. When you make edits to your code the VM is automatically updated.

As of Vagrant 1.6 (April 2014), Vagrant started supporting Windows as the server environment. This was a smart business move for Vagrant (if I dare use the word business in the same sentence as an open source project). With 1.6, supporting Windows virtual machines is a major step for Vagrant to be universal and not just a *nix tool for all the l33t people working LAMP / MEAN variants on Macs and Linux.

Web Based IDEs to challenge local development:

A Web Based IDE will have to be downright amazing to get developers to switch in large numbers. It has to have a super fast search feature, auto complete, syntax highlighting, code formatting, and lots of flexibility. Remember, software development is like herding cats, so it has to work with everyone’s finicky little idiosyncrasies. Editing code aside, it will flop without a powerful plugin architecture. I would expect a rich ecosystem of utilities including a database explorer, command line tools, XML / JSON viewers, web services, test suite runners, file comparison, etc.

I have PyCharm, Eclipse, IntelliJ, PHPStorm, and Sublime Text currently installed on my Ubuntu development laptop. I have all that plus MSSQL Studio and Visual Studio on my Windows desktop (because some of my work does require Windows). That might be a low number of IDEs for a typical developer. For brevity, I didn’t mention text editors… That is a lot of functionality to cram into a browser, but people are out there working on it.

Here are some of the current contenders (in no particular order):

I’m not seeing an extensive plugin architecture from any of them… Maybe JetBrains can pull it off? They don’t seem to be working on anything publicly yet. From a business perspective they have no real incentive to cannibalize their current products. Besides JetBrains integrates with Vagrant via a plugin, and that solves most of the issues.

That feeling when you are stuck without a tool you need:

Developer A: The application code, the server environment, and the IDE are now in the cloud. Yes I can finally buy a Chrome Book!!!

Developer A: Wait…. what about the database??

Developer B: On the Vagrant instance or in the cloud, duh…

Developer A: Yeah, let’s all buy Chrome books!

[A trip to Best Buy, and a few minutes later…]

Developer A: Cool, the app is loading! But wait…. I want to run a query. How do you access the database?

Developer B: Umm… command line, duh…

*music from Psycho plays*

Developer A: Nooooooooooooo!!!!!!

The command prompt is not a tool I like to use for data exploration:

Don’t get me wrong, I can navigate the SQL command prompt with the best of them. But let’s be honest, it SUCKS for wading through complex data. When there are enough columns to cause line wrapping per row it gets impossible to read. What about pasting huge queries? Every mature app has at least a few queries that span multiple screens, amirite? The SQL command line REALLY SUCKS for debugging lengthy queries written by ‘intelligent’ ORM frameworks or the bastard who writes SQL using string concatenation with inline if/thens, redundant joins, wanton disregard* to formatting, and over use of sub-queries {IN(), EXISTS(), etc}.

* Wanton Disregard – legal term meaning severe negligence, extreme recklessness, not malicious but more serious than carelessness, can be evidence of gross negligence, can result in punitive damages depending on severity.

There are many examples out there of web based data explorers but they are clunky at best (take PHPMyAdmin for example). A good web based SQL explorer supports multiple tabs, allows saving of SQL, and shows a basic picture of the database entities. MySQL Workbench, HeidiSQL and MSSQL Studio are the three tools I mainly use today. In the past I’ve used Toad, Navicat and DbVisualizer. They are great tools as well. In fact paid tools are generally better.

Side note – I was really hoping the Oculus Rift DK2 would be a good platform to build an app for data exploring, but it makes me sea-sick…

What’s the actual payoff?

If we are going to outsource something, we expect to save some money too. Economically, unless I’m missing something, the payoff this new approach provides for run of the mill software development isn’t really that big.

  • If your company already has QA + staging environments, in theory you’ll catch bugs related to environment differences anyway.
  • If you don’t have QA + staging, you’ve got bigger problems to worry about than minor package differences on some contractor’s laptop.
  • Bugs come in a wide range of shapes and sizes. Even if there is a bug due to environment differences, it is a small percentage of overall bugs that happen.
  • Vagrant alone solves the issue of keeping everyone’s server environment the same, and it is free.
  • The cost savings of an ‘automatic’ environment setup is a rounding error compared to a developer’s cost per year. Crappy developers take ages to get their environment going because they don’t understand $PATH or other basics. For me it is typically under an hour to get up and running. Good software shops have scripts that assist the developer in obtaining database dumps and the like.
  • If developers all require cloud instances to be spun up during development that is an added cost on top of licenses / subscriptions for the IDE.
  • If the infrastructure running the Web Based IDE goes down, all your programmers are idle.

Where a Web Based IDE does make sense:

For certain applications, like cluster computing, or big data (where localhost is just too small), I think it makes perfect sense. In situations where high security is needed, a locked down Web IDE also makes sense (no data or code on localhost at all). This might put an end to developing over a VPN through RDC – thank god for that!

Cloud based software development tools can work in theory for just about any style of programming, even 3D-game developers. Nvidia offers a cloud gaming grid which houses an array GPUs in the cloud, renders HD video in the cloud, and streams it back to the client. If you can develop Ruby in the cloud, why can’t you do OpenGL or DirectX? At least, that is what Nvidia is saying. Sounds like fun!

>>> “there's no place like localhost... “ * 3
Posted in Application Development, Work | Tagged , , | Comments Off on Is localhost development obsolete?

Example Django Model Count and Group By Query

The Django framework abstracts the nitty gritty details of SQL with its Model library (the M in MVC). It is straight forward for standard lookups involving WHERE clauses. 10% of the time I need it to do something fancy like a GROUP BY aggregate query. This required checking the docs to see ‘how the heck do I make Django do a GROUP BY with a count(*)?‘. I’ll explain in detail below with examples. Django has a method called raw() for running custom SQL, but that is a last resort. Thankfully Django supports this case really well and did exactly what I was expecting.

This information applies to Django 1.8.2.

Example ‘Bike’ model:

In this example, the Bike model has paint color, seat color, and category:

class Bike(models.Model):
    name = models.CharField(max_length=50)
    paint_color = models.CharField(max_length=255)
    seat_color = models.CharField(max_length=255)
    category = models.CharField(max_length=255)
    active = models.BooleanField()

The SQL I wanted Django’s Model to run for me:

SELECT paint_color, count(*) 
FROM bike
WHERE 
  paint_color IS NOT NULL AND
  paint_color != '' AND
  active = 1
GROUP BY paint_color
ORDER BY paint_color;

-- same thing for seat_color and category
SELECT seat_color, count(*) 
FROM bike
WHERE 
  seat_color IS NOT NULL AND
  seat_color != '' AND
  active = 1
GROUP BY seat_color
ORDER BY seat_color;

SELECT category, count(*) 
FROM bike
WHERE 
  category IS NOT NULL AND
  category != '' AND
  active = 1
GROUP BY category
ORDER BY category;

My report needs a count of all the active bikes by paint_color, by seat_color, and by category. Note that the columns allow null and empty string, so those need to be filtered out of the report.

How to do the GROUP BY / count(*) with Django:

Bike.objects.filter(active=1)
  .exclude(paint_color__exact='')
  .exclude(paint_color__isnull=True)
  .values('paint_color')
  .annotate(total=Count('paint_color'))
  .order_by('paint_color'))

For more details see the documentation page on Django Aggregation.

The call returns a list of dictionaries like so:

[
 {'paint_color': u'Green', 'total': 15},
 {'paint_color': u'Blue', 'total': 19},
 {'paint_color': u'Yellow', 'total': 4}
]

Getting fancy – allowing dynamic column substitution by variable name:

The code above is a start, but I don’t want to have three copies of that lengthy model query floating around in my code. This calls for converting ‘paint_color’ into a parameter. I also opted to go with a static method, which I can do like so on the Bike model:

@staticmethod
def summary_report(fieldname):
  allowed_fields = ('paint_color', 'seat_color', 'category')
  if fieldname not in allowed_fields:
    return {}

  return (Bike.objects.filter(active=1)
             .exclude(**{fieldname + '__exact': ''})
             .exclude(**{fieldname + '__isnull': True})
             .values(fieldname)
             .annotate(total=Count(fieldname))
             .order_by(fieldname))

Now the parameter fieldname takes the place of the hard coded string. In the spirit of defensive coding, the method checks to make sure that fieldname is an authorized property on the Bike model in this context. It could also throw exception, log an error, etc, but it is kept simple for this example.  From there, the exclude() calls use **kwargs (keyword arguments) to pass in the dynamic value.

The data for the Bike report can be obtained as follows:

summary_paint_color = Bike.summary_report('paint_color')
summary_seat_color = Bike.summary_report('seat_color')
summary_category = Bike.summary_report('category')

How to see what SQL Django Query generated?

As I was working on this, I needed an easy way to see what SQL Django was generating behind the scenes. Django Debug Toolbar does it nicely.

To install the Django Debug Toolbar it takes just two steps:

$ pip install django-debug-toolbar

Then add ‘debug_toolbar’ to your INSTALLED_APPS. It requires django.contrib.staticfiles. Refresh your page, and you’ll see the debug toolbar come up:

django_toolbar

Hope this helps!

 

Posted in Application Development, Code | Tagged , , , | Comments Off on Example Django Model Count and Group By Query

Design your own GitHub activity graph, mine is a DNA spiral

I recently turned my github activity graph into an 8-bit looking DNA spiral!

github_contributions

By setting GIT_AUTHOR_DATE and GIT_COMMITTER_DATE it is possible to log a commit at any point in time. The tool I wrote allows you to draw a pattern sort of like a mashup of mine sweeper and MS paint for windows 3.1. Then it generates the commits that match that pattern.

Here is the page where you can build your own. If you come up with something cool to put on your profile I’d love to see it. For the record, this wasn’t an original idea. Others have done similar projects (which I reference at the bottom of the tool), but none let you draw right there in the page. This was purely for fun and only took me a few hours to knock out and test.

Posted in Fun Nerdy | Tagged , , | Comments Off on Design your own GitHub activity graph, mine is a DNA spiral

Mastery over Negativity – Dealing with Negative Geeks

I think it is okay to be negative about a given software technology, but it has to be for the right technical reasons in the context of the problem at hand. For the most part what goes on is bashing with scant substance behind it. Thankfully that sort of bashing can safely be ignored, but it is not always easy.  We software developers take our work with pride. Hey, I even claim that ‘software is my life’.

A fellow Portland software developer wrote a post on negativity in the software profession, why it is lame, and some steps to address it.

“PHP, possibly the most made fun of language, doesn’t even get a reason most of the time. It is just ‘lulz php is bad, right gaise?’” – Wraithan

This inspired me to break down where the negativity comes from and how to address it in a positive way. As a software developer I am compelled to categorize and organize things, so here goes…

Why are they snickering at that technology and how can I help them see their folly?

Mono-lingual programmers – It is natural to see your first language as the best in the world. It is also the ONLY language you know, so by default it is the best. My advice is get familiar with multiple languages. That way you can contrast the pros and cons of each language. Now you have a shot at being a master programmer.

Distrust of the unfamiliar – It is human nature to distrust the unfamiliar. This is true no matter how many languages a person knows. Bashing something because you don’t know it is forgivable but screams low emotional intelligence and a weak mind. If I’m pretty sure someone doesn’t know what they are talking about, I try to point out a couple really cool things about what they are bashing and hopefully get them excited about it.

Hubris and self confirmation bias – Again, human nature at play, overconfidence can cause bias. Programmers build up deep specializations spanning many years of experience in a given area. They may even get fancy titles like Principle or Lead, and consider themselves a ‘master’. It is easy to fall into the trap of thinking the skills you’ve worked so hard to attain are the ‘best’ skills. When an alpha geek is bashing something, what I like to do is point out that what they are saying may very well be the case for a given set of problems at the moment.  Or with a specific version.  Nothing in software stays the same for very long.  Ignoring that is a failure to recognize how fast technology changes.  A good alpha geek will appreciate that point. Take JavaScript for example, when it started everybody completely hated it! Now JavaScript is everywhere and has gotten a lot better than it used to be. In fact, some the highest paying jobs as of 2015 are for JavaScript engineers, not Java engineers or C++ engineers like it use to be in 2005. In 2025 who knows what it will be?

People trying to sound smartThis news article talks about how negative people tend to be viewed as more intelligent. There is a trick to seeing through that. Are they pointing out drawbacks relevant to a task? Okay, that is fine. For example, PHP sucks at building flight control software because it isn’t multi-threaded. Agreed! Or are they pointing out weaknesses that may amount to personal preference or fail to address a specific situation? PHP sucks because it uses globals. Yeah that isn’t perfect, but you are not forced to use globals in PHP. Every language has pitfalls that should be avoided.  If they are not being specific, call it out, make them be specific so they can be more helpful.

Jerks and Gits – The haters be hating… I avoid these people when possible. Some are truly too smart for their own good. Others are frustrated sub-geniuses who feel the world owes them fame. You might be able to learn a trick or two from their criticism. Getting to know them is rarely worth the effort because sooner or later they’ll start hating on you. It amuses me when people publicly (and permanently) reveal this trait on social media or forums, thinking they are being clever.

Concluding Thoughts:

It is wise to see all languages / technologies for what they are: tools.

A software tool is not an extension of one’s identity or ego… unless you actually wrote it. Even then it is best to keep emotional distance from it. If you did write something that became famous I hope for your sake the online bashing and endless stream of bug fix and feature requests did not get to your soul.

Master software developers know that everything has limitations, and they also know what gets the job done. No software is perfect. To launch software on time within budget requires artful compromises.

Posted in For New Developers, Work | Tagged , , | Comments Off on Mastery over Negativity – Dealing with Negative Geeks

Sending emails through Comcast on Ubuntu using ssmtp

Ssmpt is a light weight mail package that is easy to configure and suitable for my needs during local development. It is basically a mail forwarder, can’t receive email, and has very few settings relative to a program like sendmail.

Comcast is notorious for requiring email sent on its network to go through its smtp server. Not doing that can get your IP blacklisted and your legitimate emails flagged as spam. I resisted but was assimilated. These settings should work for most ISPs, not just Comcast.

Install ssmtp:

sudo apt-get install ssmtp

Configure ssmpt for Comcast:

You must setup an account with our ISP / email provider and enter the email/password below. I use a dedicated email account for development.

sudo vi /etc/ssmtp/ssmtp.conf

ssmpt.conf content:

root=postmaster
mailhub=smtp.comcast.net:587
UseSTARTTLS=YES
UseTLS=YES
AuthUser=myaccount@comcast.net
AuthPass=****
hostname=mymachine
FromLineOverride=YES

To test it out:

First save a test message in the ssmtp format, here is how my file looks:

$ cat testmessage.txt
To: youremail@gmail.com
From: you@comcast.net
Subject: test message

Test message for ssmtp.

To send the message:

ssmtp youremail@gmail.com < testmessage.txt

For PHP compatibility:

Edit php.ini, look for the sendmail section, set the following:

sendmail_path = /usr/sbin/ssmtp -t

Last step: restart apache

Posted in Sys Admin | Tagged , | Comments Off on Sending emails through Comcast on Ubuntu using ssmtp

A KeePass setting that might save your online identity

Your KeePass file might not be as safe as you think, but it is easy to protect yourself with this simple settings change that does not require creating a new kdbx file. This helps make your KeePass file more secure by deterring dictionary and brute force attacks.

The setting is called ‘Key Transformation’, accessible in KeePass under File > Database Settings… > Security. This screenshot is of version 2.x, but 1.x also has this feature (minus the helpful one second delay button).

KeePass Transform Key Settting

What it does is run the master key through N rounds of encryption before applying it. The higher the N, the more time it takes your CPU to process through all the rounds of encryption. The default is 6000 which takes less than a millisecond for a modern CPU to churn through. My setting is in the high 7 figures, and takes about one second. That is a delay I can live with each time I attempt to open my KeePass file. In fact it kind of feels good to be reminded the program is doing extra work to protect me.

The reason for introducing a delay is to slow down a brute force attack to the point it is unfeasible in this lifetime. A brute force attack starts by trying every character (A-Z, a-z, 0-9, symbols), then every two character combination (aa, ab, ac…), then every three character combination (aaa, aab, aac), and so on. A related approach, called a dictionary attack, loops through a dictionary and tries all words and various combinations of words with different delimiters. Eventually these approaches will find the master password. However, when N is a high enough number, it will cost the attacker one second per attack (per CPU), which is a serious roadblock.

If your password is sufficiently strong, say 30 random characters including A-Z, a-z, 0-9, and 10 different possible symbols, that is 72 characters to draw from. That results in 72^30 = 5.24e+55 possible combinations! Only an attacker with a huge number of CPUs or a huge amount of time would be able to check all combinations. I doubt this little technique would deter high level national security organizations with billions of dollars in funding. However, I have a strong sense that a high N would deter script kiddies and cracking programs.

As CPUs get faster, N needs to increase to offset the time it takes to attempt a single crack at the master password. I plan to increase the value every time I get a new machine.

What the ‘average’ user sets their password to:

You know it really isn’t very hard to achieve ‘better than average’ password security. Most people use the password ‘password’ or ‘123456’, and tend to use the same password for all their accounts.

Going beyond just a strong password:

A full proof password may not be enough. Wired did a thorough write up on how a weak password and social engineering combined with a basic flaw in processes at Amazon and Apple lead to journalist losing his entire online identity.  That is why I always setup the extra identity verification questions under my account. I never use the same Q&A twice. I also use three different emails: personal, work, and private / banking. That way even in the worst case scenario where a hacker is able to trigger password resets and get into accounts the scope of the damage is limited.

What is KeePass?

For those who don’t know, KeePass is a FOSS program for managing passwords. One ‘master’ password gets you into all your other passwords. It can easily generate strong passwords. In fact, I don’t even know some of my passwords since they were generated inside KeePass with the ***’s showing. From there I pasted the value it made into whatever website’s sign-in form I was at. I then immediately make a secure backup of the KeePass file so I don’t lose that new password. The coolest thing is the Ctl+V feature that will tab back to the previous window, paste your username, tab, paste your password, and then hit enter to submit the form.

I’ve been using KeePass to manage my passwords for almost a decade. What I really like about it is how portable it is between Linux, Mac, and Windows. It also has ports to all manners of tablets and smart phones – but I would never put such a sensitive file on something that doesn’t have an encrypted drive.

Is KeePass secure?

I have not read the source and can’t vouch for it. I just know a lot of other software professionals who also use it. The fact that it is open source makes me feel better about it. It does encourage temporarily putting passwords into the system clipboard, which is arguably an insecure spot. Typing a complex password has its downsides too a) it takes time, and b) keystroke listeners would be able to pick them up.

Here is an interesting article about someone who was tasked with cracking a KeePass file. The article doesn’t say how they cracked it, but the YouTube video comments say they “found it written on a piece of paper.”

LOL!

So the moral is, KeePass is as insecure as its operator is careless.

Posted in Business, Work | Tagged , | Comments Off on A KeePass setting that might save your online identity

Why I use GitHub (or Bitbucket) at every chance, and why you should too

When I work on projects that don’t have GitHub or Bitbucket, I really miss it. It is the little things they do that speed things along and get me access to what I need in a way that looks visually pleasing.

github

bitbucket

This is not meant to offend, but for me GitHub and Bitbucket are pretty much the same thing. BitBucket originally attracted me due to its free private repos. All the work I do is under NDA, meaning it is confidential. The code is usually owned by whoever I’m working for, so privacy really matters. In the course of my work I’ve used both GitHub and Bitbucket extensively. For my purposes I really can’t distinguish between them. Others have tried recently. It seems to come down to nuances between open source vs enterprise development. That aside, I’ll just call the pair GitHub from now on so I don’t have to repeat myself.

5-speed manual vs automatic:

The difference between a project with and without GitHub, is sort of like owning a car with a automatic transmission vs a 5 speed manual.

I used to own an old BMW 3 series with a 5-speed (technically an E30). It had 3 floor pedals, the extra being the clutch for shifting gears. That car was a blast to drive! It had a tachometer in the dash too. I remember always being impressed that in 5th gear the speedometer and the tachometer were parallel. Pretty cool design and engineering philosophy by BMW. I just loved the way it responded, even though it had 180k miles when I bought it. Yeah it was expensive to maintain, but I was infatuated.

Sadly, this is less common today, but I also learned to drive on a manual. Just after my sixteenth birthday I took my drivers test with a 5-speed Corolla. During the test I conked it out twice but still passed by one point.

That is the good and bad about the manual: it is more work, can be slower to shift and fatiguing to drive, but in the right hands, when you down shift and punch it out of a corner there is nothing like it! It does just what you expect it to do at all times.

The enjoyment of shifting gears:

When it comes source control, git command line is my sporty 5-speed manual. I use git exclusively on the command line. I know my limits (by no means am I a git guru), but I get the job done day in and day out. It brings satisfaction in the familiar routine of going through the gears (pull, commit, push and the occasional merge/rebase). Everybody I know who can switch to git already has.

Sorry Subversion:

I suppose SVN is now the equivalent of an old rust bucket with a 3-speed on the column without a synchro (double clutch to get back into first). Sorry SVN, you were a trusty pal back in the day.

The ease of driving an automatic:

Using GitHub on top of git is what I consider an ‘automatic’. It does a lot of nice stuff intuitively that I don’t have to work at or think about to much.

My main use of GitHub is the web interface for browsing the repo. I love being able to compare branches, look at commits, study code, go back in time, make inline comments, etc, etc. The coloring of the output is very clear as to what is new code, what was removed, and which lines were changed. I will often have a handful of GitHub tabs open at once to get caught up on recent commits. Reading code recently committed by your team members is a good habit, even if not required by management.

To that point, fixing a bug correctly (without breaking something else) almost always involves determining its origins. With GitHub it is very handy to be able to literally ‘click’ into the past and search for keywords at a certain point, and then correlate those changes to commit messages. Then you know who to take the nerf bat to.

I have tried desktop GUI tools on Ubuntu and Windows for browsing repo history. They all come up way short and remind me of Windows 3.1 programs. The command line can be used for looking at recent changes and even code archaeology, but in practice it becomes too much to wade through.

Managing pull requests in GitHub is really nice too. It will even warn you if there is a merge conflict in advance. The built in wiki’s are nice. The Readme.md markdown formatting is nice.

A project run through GitHub (or BitBucket) makes my work day easier, makes collaboration easier, and helps me feel like I’m right there with the rest of the team when I’m working remotely.

With git command line and GitHub, we get the best of both worlds. The pleasure of the 5-speed (git cli), and the convenience of the automatic (GitHub). Okay it’s not a perfect analogy…

Some alternatives for the DIY project:

Don’t want to tie yourself to GitHub or BitBucket? I don’t blame you. There are many business cases for keeping code on servers you and only you control.

These projects are web based repo browsers that work similar to GitHub:

Posted in Code, Work | Tagged , | Comments Off on Why I use GitHub (or Bitbucket) at every chance, and why you should too

The Software Maintenance Efficiency Curve

I have been told “there is no such thing as green field development”. While that statement is false for the hobbyist developer, in the business world it is nearly true. Those who code for a hobby or for pure enjoyment often start from scratch, as evidenced by the explosion of unmaintained projects on Github. See my article about software ghettos for more on that. When it comes to software used in the real world, open source or not, maintenance is an everyday task.

Consider what goes on between the 1.0 and 1.1 release. Was that 100% new work or did it include some maintenance to allow the 1.1 features to fit with the 1.0 architecture? Now fast forward to the 1.8 release, was the ratio of maintenance higher? Almost certainly.

An article by Robert Glass in IEEE Software May/June 2001 called Frequently Forgotten Fundamental Facts about Software Engineering states maintenance is 40-80% of software cost, and enhancements contribute to 60% of new maintenance costs!

Why care about quality?

Consider that businesses are not interested in (and probably can’t afford) a monument to computer science. What the average business demands is functional code. I have been involved with dozens of businesses, small, large, tech centric, and technophobic – none have asked for fancy or perfect code. Anything beyond functional is seen as a waste, and I agree. This is not a license to take shortcuts and hack things together. If shown the distinction a business doesn’t want a ghetto code base with anti-patterns everywhere that will soon become unmaintainable and cause developers to run and hide. In spite of this, it turns out a lot of systems are managed in a manner that contributes to major system outages, security holes, developer attrition, and occasionally huge monetary losses. Google ‘stock market glitch‘ for examples.

How can software maintenance work be done efficiently?

A great developer won’t make much of a dent if they are blocked from doing so. The product owner should have a long term plan for the system which includes keeping the system healthy and maintainable. That plan should favor fixing existing bugs (see #5 on Joel’s list) and allocate time for paying down technical debt in each release. Technologies such as source control, a suite of unit tests, code linting and build automation are extremely helpful. Policies on code style, documentation, learning, and knowledge sharing make a big difference too.

A team composed of a mix of veterans, mid level staff, and junior developers makes for a healthy balance. The developers should be allowed to think they own it (a variation on a famous quote from Bill Gates). A culture of knowledge sharing should be encouraged and rewarded. Assumption checking should be considered normal and non-threatening. Have you ever read a spec that was 100% free of half baked assumptions? Individual performance should take a back seat to team performance. Otherwise silos form, the incentives become twisted, and so does the code.

On the individual level a developer has three hills to climb to become maximally efficient:
1) The languages, libraries, and technologies used in the system.
2) The domain (the nature of the business).
3) The way the system was setup.

Languages and libraries should be a relatively low hurdle if the technologies used are ubiquitous and the right skills are hired for. Domain knowledge is harder to come by. In some areas such as insurance, finance, education, or ERP a person with the right experience is attainable. The third hurdle is by far the least visible to the business and the most challenging. It ultimately comes down to what is stuck inside the developer’s head that makes them efficient at maintaining the system. If the developer wrote the system from scratch, they get past that for free. That assumes they haven’t already moved on… perhaps washing their hands of a mess?

“Debugging is like farting – it’s not so bad when it’s your own code” – Unknown

The time it takes to attain mastery over a code base is proportional to its size and complexity. The best approach is to start with an easy task, then something slightly more complex in a different part of the system, then something in a third area, and finally circling back to the first area for a real challenge. This way confidence is built up steadily and the risk of breaking something critical is reduced.

The first few days to several months of working on an unknown system are the most stressful and error prone for a developer. Without knowing every aspect of the system it is easy to accidentally write new bugs. Without a senior developer or product manager to explain things it can be very confusing and frustrating to make headway. This is where developers with solid people skills and high self esteem will shine because they are not afraid to ask for help and are effective at getting good answers.

Development efficiency increases over time then plateaus:

Software Maintenance Efficiency Curve

The orientation phase and steepness of the growth phase increase relative to the size of the system. They can be shortened with documentation, clean code, but most importantly friendly and knowledgeable team members. Hiring for a person with knowledge of the languages, libraries, and domain also helps.

Let’s say things go well, and the developer climbs the efficiency curve after X days or weeks. Now they are really ‘making money’ for the business. This is the most efficient place for the developer to be business wise. The length of time a developer spends on top of the curve depends entirely on the company’s ability to retain that developer. The going advice is to pay at least a fair wage, be flexible, be organized, then stand back and let them go. Make sure to let them do interesting things from time to time. Offices with windows, sit stand desks, and flexible hours are nice perks that don’t cost much when averaged out. The alternative is to loose the developer and go back to square one in the orientation phase with someone new.

Posted in Application Development, Business, For New Developers | Tagged , , , | Comments Off on The Software Maintenance Efficiency Curve