Jim Lynch Codes
  • Blog
  • About Jim

Writings about one coder's stories & experiences.

3 Tips For Building Better Software, Faster.

2/17/2020

0 Comments

 
During my time working as an engineer and software consultant I've been on some brilliant teams that were able to build incredible things in a very short amount of time. I've also been on teams that are, ehh, not so agile... Indeed, when I look up Google's definition for the word agile right now the first entry is, "able to move quickly and easily".

Although there are many flavors of
agile development that all emphasize slightly different concerns, in this article I'd like to discuss three things that I consistently see done by the top software teams. I believe that any engineering team not already practicing these three things can get an immediate productivity boost by implementing them well.

​So without further ado, let's get into it!

1. ​Leverage Automated Tests

​Automated testing, when used correctly, can be an incredibly useful tool for moving faster without sacrificing accuracy. Unit tests and end-to-end tests are the yin and yang that complement each other that together give you the awareness of where your code is broken when they fail and the confidence that the code you're about to ship works when they pass.

​Notice, though, that I say
leverage automated tests. A few times I've seen test automation get out of control to be the point where they become unwieldy, too many tests checking the same things, etc. Don't let this happen to your team! Teach your team members to appreciate testing as a tool for them to leverage rather than a new goal of chasing green 100's on the code coverage reports. 
More often though I see teams that naively write and ship code without any automated at all. Sure, this will work a few times in the beginning, but it quickly becomes unscalable, prone to human error, and turns the developers into manual testers. Ironically, throwing more people at the problem makes things worse, the software progresses way too slowly, and the project ultimately fails. ​
Meanwhile, the teams with unit tests all throughout the stack, with UI specs written in gherkin and executed against their front-ends using tools like Cypress.io, with backend endpoint tests run through something like Newman, with these tests all automatically run on a CI / CD server... these teams are able to stay lean while building intricate systems things that work flawlessly and are shipped frequently.

2. Work In Pairs

In my previous consulting project I was blessed with the opportunity to work on a team where everyone was on board with pair programming. Overall, it was a really great experience for me and showed me that pair programming gets the team to the end goal faster and easier than the "solo work" model.

Solo work is a cute derogatory term we invented for the traditional scrum "divy up the work and have everyone go their separate ways" methodology for developing software. The solo work model is just objectively slow, painful, and incredibly inefficient.

​When one developer has to figure everything out on his or her own it can take a very long time before any working code gets written. Possibly the developer goes down a path that the team doesn't particularly like, but in this model the feedback isn't given until a week later when a pull request is opened, and then people start ripping it apart asking for it to be almost completely rewritten...
​On a different note, all of the engineers have vastly different experiences and expertise, and that knowledge gets shared across the engineers within the team exponentially more when pairing. Pairing is great because is shortens the feedback loop virtually to zero.

Indeed, pair programming is basically constant, continuous code review throughout the entire development of the code. Naive non-technical managers sometimes think that because the engineers can write half as many lines of code then in turn it will take twice as long to ship the feature.

​Ha! To me, this is obviously complete foolishness since lines of code is hardly ever the bottleneck in software development- rather, the real cost of software is in the ongoing maintenance of the code- how quickly and easily it can be understood and updated with new features and patches. 
​Pairing partners can keep each other honest by calling each other out when they are about to take shortcuts, practicing disciplined test-first TDD, and coming up with good names for things early on. When you work in pairs correctly there is often much less "re-work", much more high-fiving, and much higher quality code.

Some engineers are afraid to try pair programming at first, but I have found that even the most introverted coders can be more efficient and more helpful to the team when pairing.

​Also, when everyone is pair programming I know they are truly engaged in the work and so as a manager and team lead I have no negative feelings when people take breaks or leave early because I know that they are working hard.

3. Keep It Simple

​"There are many ways to skin a cat" is pretty disturbing idiom if you think about it literally, but the idea is that there are often many different ways to accomplish something.

​In the great talk by Rich Hickey, "Simple Made Easy", he argues that as a programmer you should try to use tools that are simple and that will allow you to build simple solutions for your problems. All too often I see teams creating giant, monstrously complex systems when it's just unnecessary. 
-> ​Keep it simple on your web front-ends by using a modern framework that allows you to break things down into focused, declarative components.

-> Keep things simple in your infrastructure by hosting both your front-ends and back-ends with a serverless architecture.

-> Keep things simple in your database by choosing a db that represents and stores data in the same form that your front-ends want to consume it (these days, probably JSON).

​Of course, simplicity is a pretty subjective topic as what's simple to one person may not seem so simple to another, but still- striving to keep your systems simple is a great rule of thumb. 
​One engineer may think JavaScript is the most simple because that's what actually runs on the NodeJS, and you don't need to understand all the "extra" rules of other compile-to-JS languages.

Another engineer might say TypeScript is the most simple because in code written with it you can clearly see the shape of the data that's being passed around between functions.

Then yet another engineer may argue that ClojureScript is the most simple because of its succinctness and expression-based nature.

​Personally, I think they can all be correct and as with any subjective discussion it's all a matter of perspective. My advice would be to have opinions of your own but also stay open-minded, don't push people too far outside of their comfort zones, and just keep it simple.

Are You Convinced Yet?

I'm very curious to hear how other software engineers feel about these tips. In practice, I see very few teams even attempting to utilize TDD and pair-programming, let alone do it at the highest level.

I have been fortunate enough to have worked with and learned from some incredibly talented engineers, and I truly believe that incorporating these three tips into your team's workflow will have a profound effect on the team's efficiency and the overall quality of the code.

​If your team is struggling to adopt these practices, we can help! At Evaluates2 we provide group workshops, full-time on-site consultants, and impartial expert opinions to help you and your team(s) build better software, faster. Don't hesitate to contact us today!
0 Comments

Your comment will be posted after it is approved.


Leave a Reply.

    ​Author

    Picture
    The posts on this site are written and maintained by Jim Lynch. About Jim...
    Picture
    Follow @JimLynchCodes
    Follow @JimLynchCodes

    Categories

    All
    Actionscript 3
    Angular
    AngularJS
    Automated Testing
    AWS Lambda
    Behavior Driven Development
    Blockchain
    Blogging
    Business Building
    C#
    C / C++
    ClojureScript / Clojure
    Coding
    Community Service
    CS Philosophy
    Css / Scss
    Dev Ops
    Firebase
    Fitness
    Flash
    Front End
    Functional Programming
    Git
    Go Lang
    Haskell
    Illustrations
    Investing
    Java
    Javascript
    Lean
    Life
    Linux
    Logic Pro
    Music
    Node.js
    Planning
    Productivity
    Professionalism
    Python
    React
    Redux / Ngrx
    Refactoring
    Reusable Components
    Rust
    Security
    Serverless
    Shell Scripting
    Swift
    Test Driven Development
    Things
    TypeScript
    Useful Sites
    Useful Tools
    Video
    Website Development
    WebStorm
    Writing

    Archives

    March 2023
    August 2021
    February 2021
    January 2021
    October 2020
    September 2020
    May 2020
    April 2020
    February 2020
    January 2020
    December 2019
    October 2019
    September 2019
    August 2019
    July 2019
    June 2019
    May 2019
    April 2019
    March 2019
    February 2019
    January 2019
    December 2018
    November 2018
    October 2018
    September 2018
    August 2018
    June 2018
    May 2018
    April 2018
    March 2018
    February 2018
    January 2018
    December 2017
    November 2017
    October 2017
    September 2017
    August 2017
    July 2017
    May 2017
    April 2017
    March 2017
    February 2017
    January 2017
    December 2016
    November 2016
    October 2016
    September 2016
    August 2016
    July 2016
    June 2016
    May 2016
    April 2016
    March 2016
    February 2016
    January 2016
    December 2015
    November 2015
    October 2015

    RSS Feed

  • Blog
  • About Jim
JimLynchCodes © 2023