Don't forget your roots.

Don't forget your roots.

If your background is similar to mine, you’ve made the journey from software developer to CTO, VP or even full-stack tech organization builder. Let your team know you share their experience and professional interests by maintaining your knowledge of important technology concepts and fundamentals. If you do so, you’ll be able to engage with your team on a more personal level, and they’ll appreciate you for it. Let them know you can “talk shop” with them, no matter what aspect of the software organization you’re dealing with.

Here’s some concepts and fundamentals that I might discuss with my team on a daily basis:

Four principles of OOP:

  • Encapsulation - Hide data manipulation behind setter and getter methods.
  • Abstraction - What the consumer of the object sees specifically about that object.
  • Inheritance - Child inherits attributes and behaviors from parent.
  • Polymorphism - Redefine/add behaviors to derived classes.

Method Attributes:

  • Virtual - Lets descendant class override with same signature.
  • Override - Allows child method to override parent with same signature.
  • Overload - Shared method name, different signatures for each method.
  • Static - Can’t instantiate. Referred to by class name. State changes as a single instance.
  • Public - Callable from anywhere in code.
  • Protected - Callable only from descendant classes.
  • Private - Callable only from class it is defined in.

Interfaces: Treat as a contract. Interface based design makes code more maintainable and helps other devs use your code without having to dig into object details.

Common Design Patterns:

  • Interceptor - Insert an independent step into sequence of execution, unknown to the other steps.
  • Facade - Used to ease or simplify complicated interfaces to underlying object(s)/component(s).
  • Mediator - Helps to keep client components loosely coupled such that they don’t call each other directly. Use Delegates and Events to implement if you’re using .net languages.
  • MVC - Separates your app into three areas:
  1. Model - Data model and business domain logic. No dependencies on Controller or View.
  2. View - Presentation layer for model.
  3. Controller - Delivers data to the View.

For fun: What would be a good use of the Interceptor pattern?

Thoughts on Debugging:

Attempt to reproduce error, then analyze following:

  • The last change made to system probably broke it.
  • If not that, set broad boundaries around error event window. Iteratively shrink event window until the code committing the error is identified.
  • Use logging liberally.

For fun: What can you use if you don’t have a logging system or debugger?

Testing:

  • Test Driven Development - Write your unit tests before you start coding. A good unit test checks function output against expected output, given varying acceptable inputs. Should have 100% failure before coding is started and 100% success when coding is completed.
  • Acceptance Test Driven Development - TDD driven by business customer criteria.

Agile:

  • Acceptance Criteria - Conditions that a software product must satisfy to be accepted by customer or system.
  • Definition of Ready - User story is ready to be sprinted.
  • Definition of Done - User story meets acceptance criteria as determined by stakeholder and ATDD.
  • INVEST - A good user story is independent, negotiable, valuable, estimable, small, testable.

For fun: What’s wrong with INVEST?

QA Strategies:

  • Scope of QA can cover TDD, regression, and manual testing for UI.
  • Existing regression test scenarios should be versioned (matching release version) and automated.
  • QA should be continually creating new regression test scenarios.
  • All these scenarios provide the basis for a “Theory of Operation” for the system.
  • For each test scenario (by release version), each is identified and documented:
  1. Related components.
  2. Related system workflow with components specified.
  3. Related database schema.
  4. Related UI mockup.
  5. Related UI workflow.

For fun: What happens if you don’t automate your regression testing scenarios?

SQL/Database Stuff:

  • Inner Join - Intersection (match of values) of two tables.
  • Left Join - All records from left table plus intersection.
  • Right Join - Same as left join but other side.
  • Union - Result set of two or more selects.
  • Relationship - Data between two or more tables related via key.
  • Constraint - Key requires uniqueness or valid relationship values. Column requires specific values.
  • Normalization - Table schema does not include any data that specifies it to a particular use case or increases redundancy.

For fun: Name two techniques to allow updates in a multi-user system without using locks.

Common App Security Issues:

  • CORS (Cross Origin Resource Sharing) - Requests sent to a domain outside of hosting domain. If your website has a Same Origin Security Policy, make sure your developers understand the importance of sanitizing any possible inputs that could include domains to be fed into an Ajax request. Additionally, if your site actually depends on multiple domains to make requests to, you’ll need to build a reverse-proxy interceptor into your custom server (simple with golang), or use a great tool like Application Request Routing if you use IIS.
  • XSS (Cross site scripting) - Script injection attack. A website is susceptible to script injection if related input data is not sanitized before the page that uses it is generated (as in a templated site).
  • SQL Injection - If URL query parameters or form data are sent directly into a SQL statement on the back end, an attacker could wreak havoc on your data or force your application to return unintended data results. Once again, this is an issue solved by proper input sanitization. Always make sure your devs validate input data, and make judicious use of parameterized SQL queries and stored procs.

For fun: How do you safely open up your website to free-form SQL queries (as with a report generator)?

Cloud Services:

Cloud providers (Azure, AWS, Google Cloud, Cloud Foundry, etc) represent the future of computing. Much of the work done traditionally by On-Premise infrastructure can now be off-loaded to cloud providers. It’s important to understand the different services that the cloud can provide.

  • Iaas (Infrastructure as a Service) - As opposed to On-prem, your infrastructure team no longer has to deal with any virtualization, physical hardware, or networking. However, your infrastructure team will still need to manage any O/S, application, web, database, etc. requirements.
  • PaaS (Platform as a Service) - This service provides the most value if your infrastructure can be reduced to necessary applications and data.
  • SaaS (Software as a Service) - Your own infrastructure team is not required for any of your computing needs. Example: you use Google Apps or Azure hosted Dynamics CRM to run your business.

Infrastructure as Code - A crucial aspect of understanding the conceptual shift from traditional infrastructure work and building infrastructure as it’s done in the cloud. For instance, with traditional infrastructure, your team might have to swap a drive out to increase space on a database server. With cloud infrastructure, any work like this is accomplished in code, to wit:

# Select data disk

$disk = $vm.StorageProfile.DataDisks | Out-GridView `

-Title "Select a data disk" `

-PassThru

# Specify a larger size for the data disk

$size = Read-Host `

-Prompt "New size in GB"

Run some code like this in Powershell, and that’s all you have to do to bump up needed drive space.

Want to grow the best tech team possible? Don’t forget your roots, keep your knowledge current, and engage with your teams on a regular basis. What’s your experience on this subject?

There’s a lot more that can be covered here. How about SOLID principles? Version control branching strategies? Maybe how to work an Operations Kanban Board? How to really apply good SDLC? How to build software development matrix organizations? I’ll be taking a look at all these subjects in the future.

Until next time,

slàinte mhath!

James Smith has a 25 year career building software and organizations for a multitude of industries. He enjoys working with startups to large organizations, has held several highland games world records, and has pitched to VC using nothing more than napkin drawings and a bowl of M and M's. 











要查看或添加评论,请登录

James Smith的更多文章

社区洞察

其他会员也浏览了